perm filename CLWIND.MSG[COM,LSP]16 blob
sn#843058 filedate 1987-07-16 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00176 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00026 00002 Introduction
C00029 00003 ∂23-Sep-84 1610 RPG Introduction
C00032 00004 ∂02-Oct-84 1311 RPG Chairman
C00033 00005 ∂13-Oct-84 1440 RPG Chairman
C00034 00006 ∂25-Oct-84 0944 FILE-SERVER%WHITE.SWW.Symbolics@SCRC-RIVERSIDE.ARPA Chairman
C00037 00007 ∂27-Oct-84 2148 RPG Hello folks
C00040 00008 ∂28-Oct-84 1054 DDYER@USC-ISIB.ARPA Initial questions
C00042 00009 ∂29-Oct-84 0917 DDYER@USC-ISIB.ARPA Initial Answer
C00047 00010 ∂29-Oct-84 1045 boetje@DEC-HUDSON some initial answers(?)
C00061 00011 ∂30-Oct-84 0711 dzg@cmu-cs-spice.arpa Terminology, etc.
C00067 00012 ∂31-Oct-84 0723 STENGER%ti-csl.csnet@csnet-relay.arpa re: inital answers
C00070 00013 ∂02-Nov-84 2330 DDYER@USC-ISIB.ARPA Real devices (mainly)
C00075 00014 ∂03-Nov-84 0747 FAHLMAN@CMU-CS-C.ARPA Goals
C00081 00015 ∂04-Nov-84 1816 JW-PETERSON@UTAH-20.ARPA Some responses...
C00084 00016 ∂19-Nov-84 0019 DDYER@USC-ISIB.ARPA Proposals and questions
C00088 00017 ∂19-Nov-84 2035 WHOLEY@CMU-CS-C.ARPA Proposals and questions
C00096 00018 ∂19-Nov-84 2220 FAHLMAN@CMU-CS-C.ARPA Proposals and questions
C00100 00019 ∂20-Nov-84 0736 boetje@DEC-HUDSON documenting implementations
C00105 00020 ∂20-Nov-84 0850 WHOLEY@CMU-CS-C.ARPA Virtual Displays
C00113 00021 ∂21-Nov-84 0724 FAHLMAN@CMU-CS-C.ARPA Virtual Displays
C00119 00022 ∂21-Nov-84 0914 DDYER@USC-ISIB.ARPA Implementation strategy
C00123 00023 ∂21-Nov-84 1048 KACZMAREK@USC-ISIF.ARPA Re: Virtual Displays
C00126 00024 ∂21-Nov-84 1250 greek@DEC-HUDSON Terminal features and graphic functions
C00129 00025 ∂21-Nov-84 1434 @MIT-MC:MONTALVO@MIT-OZ Re: Virtual Displays
C00131 00026 ∂26-Nov-84 0717 boetje@DEC-HUDSON graphics, virtual displays, and terminals
C00137 00027 ∂08-Dec-84 1642 DDYER@USC-ISIB.ARPA Easy Questions
C00139 00028 ∂08-Dec-84 1927 FAHLMAN@CMU-CS-C.ARPA Easy Questions
C00143 00029 ∂11-Dec-84 1207 DDYER@USC-ISIB.ARPA Re: Easy questions
C00151 00030 ∂12-Dec-84 2201 RAM@CMU-CS-C.ARPA Easy Questions
C00157 00031 ∂09-Jan-85 0110 DDYER@USC-ISIB.ARPA This space intentionally left blank
C00159 00032 ∂09-Jan-85 1001 KACZMAREK@USC-ISIF.ARPA Dire Dyer Prediction
C00162 00033 ∂09-Jan-85 1117 DDYER@USC-ISIB.ARPA Re: This space intentionally left blank
C00164 00034 ∂09-Jan-85 1322 boetje@DEC-HUDSON here's something to make up for the long silence... Jerry
C00267 00035 ∂09-Jan-85 1420 @MIT-MC:Henry%MIT-OZ@SCRC-RIVERSIDE Silence breaker
C00270 00036 ∂20-Mar-85 2048 DDYER@USC-ISIB.ARPA ANSI windows
C00273 00037 ∂20-Mar-85 2113 DDYER@USC-ISIB.ARPA ANSI windows (II)
C00275 00038 ∂29-Jul-85 1235 Fischer.pa@Xerox.ARPA RE: Clearing the screen and other such things.
C00277 00039 ∂29-Jul-85 2307 DDYER@USC-ISIB.ARPA Clearing the screen etc.
C00280 00040 ∂30-Jul-85 0915 STENGER%ti-csl.csnet@csnet-relay.arpa Re: Clearing the screen etc.
C00286 00041 ∂17-Dec-85 2157 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA
C00287 00042 ∂16-Dec-86 1905 RICHER@SUMEX-AIM.STANFORD.EDU CL-WINDOWS mailing list
C00293 00043 ∂16-Dec-86 2254 RICHER@SUMEX-AIM.STANFORD.EDU purpose of mailing list
C00296 00044 ∂17-Dec-86 0556 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU X server implementors?
C00298 00045 ∂17-Dec-86 2251 RICHER@SUMEX-AIM.STANFORD.EDU a bunch of messages on X/News & Commonlisp
C00324 00046 ∂26-Dec-86 1428 RICHER@SUMEX-AIM.STANFORD.EDU [Ralph R. Swick <swick@ATHENA.MIT.EDU>: User Interface Toolkit proposal]
C00329 00047 ∂26-Dec-86 1437 RICHER@SUMEX-AIM.STANFORD.EDU [kddlab!elis03@vc.sra.junet (Ken Seo): x-window in lisp]
C00333 00048 ∂26-Dec-86 1753 gabriel@vaxa.isi.edu cl-windows mailing list
C00334 00049 ∂27-Dec-86 0958 ho@ucbarpa.Berkeley.EDU CL-windows
C00335 00050 ∂27-Dec-86 1556 wanginst!ulowell!ulowell.ULOWELL.EDU!grinstei@harvard.HARVARD.EDU please add me to the list
C00337 00051 ∂28-Dec-86 0917 UEJIOWH%CADVAX.decnet@ge-crd.arpa cl-window mailing list
C00338 00052 ∂29-Dec-86 0634 PB80@A.CS.CMU.EDU Add to mailing list please
C00339 00053 ∂29-Dec-86 0839 spe@cad.cs.cmu.edu Please add me
C00340 00054 ∂29-Dec-86 0946 @KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU X in lisp
C00343 00055 ∂29-Dec-86 1129 RICHER@SUMEX-AIM.STANFORD.EDU Re: CL-WINDOWS mailing list
C00345 00056 ∂30-Dec-86 0719 pyramid!pyramid.UUCP!bein@hplabs.HP.COM mailing list request..
C00346 00057 ∂30-Dec-86 1028 rw@cad.cs.cmu.edu mailing list
C00347 00058 ∂30-Dec-86 1312 ekberg%home%ti-csl.csnet@RELAY.CS.NET CL-WINDOWS request
C00349 00059 ∂05-Jan-87 0153 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET CL-WINDOWS
C00351 00060 ∂05-Jan-87 0328 mcvax!inria!devin@seismo.CSS.GOV mailing list
C00353 00061 ∂06-Jan-87 1246 RICHER@SUMEX-AIM.STANFORD.EDU discussion items
C00363 00062 ∂06-Jan-87 1437 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU toolkits
C00365 00063 ∂07-Jan-87 1822 sdcrdcf!stephen@LOCUS.UCLA.EDU request
C00366 00064 ∂18-Jan-87 1653 MMcM@STONY-BROOK.SCRC.Symbolics.COM discussion items
C00374 00065 ∂18-Jan-87 1726 STEINBERG@RED.RUTGERS.EDU Access to Sun windows from CL
C00376 00066 ∂18-Jan-87 1753 dcmartin@ingres.berkeley.edu Re: Access to Sun windows from CL
C00379 00067 ∂20-Jan-87 1200 RAM@C.CS.CMU.EDU X interface standard
C00386 00068 ∂21-Jan-87 1328 RICHER@SUMEX-AIM.STANFORD.EDU X/Lisp from ailist
C00390 00069 ∂21-Jan-87 1419 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU random thoughts
C00394 00070 ∂21-Jan-87 1458 @KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU X Version 11 protocol document
C00396 00071 ∂22-Jan-87 1431 RAM@C.CS.CMU.EDU random thoughts
C00403 00072 ∂22-Jan-87 1530 MMcM@STONY-BROOK.SCRC.Symbolics.COM random thoughts
C00408 00073 ∂23-Jan-87 1319 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU random thoughts
C00413 00074 ∂23-Jan-87 1423 @ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU random thoughts
C00422 00075 ∂25-Jan-87 0823 RAM@C.CS.CMU.EDU random thoughts
C00430 00076 ∂25-Jan-87 1355 MMcM@STONY-BROOK.SCRC.Symbolics.COM random thoughts
C00434 00077 ∂27-Jan-87 0346 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU random thoughts
C00441 00078 ∂27-Jan-87 0407 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU random thoughts
C00445 00079 ∂27-Jan-87 0450 Freburger.ULC@BCO-MULTICS.ARPA Mailing list
C00446 00080 ∂27-Jan-87 0920 Skef@think.com Window system psychomysticism
C00448 00081 ∂27-Jan-87 1739 RICHER@SUMEX-AIM.STANFORD.EDU Lisp interfaces to X
C00451 00082 ∂28-Jan-87 0827 dcmartin@ingres.berkeley.edu Re: Lisp interfaces to X
C00457 00083 ∂28-Jan-87 0902 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: Lisp interfaces to X
C00459 00084 ∂28-Jan-87 0953 dcmartin@ingres.berkeley.edu Re: Lisp interfaces to X
C00463 00085 ∂28-Jan-87 1242 RICHER@SUMEX-AIM.STANFORD.EDU Re: Lisp interfaces to X
C00469 00086 ∂28-Jan-87 1246 primerd!doug@enx.prime.pdn Re: Lisp window systems standardization
C00472 00087 ∂28-Jan-87 1356 FAHLMAN@C.CS.CMU.EDU Lisp interfaces to X
C00478 00088 ∂28-Jan-87 1429 TAYLOR%PLU@ames-io.ARPA Window Systems Survey
C00496 00089 ∂28-Jan-87 1430 RICHER@SUMEX-AIM.STANFORD.EDU Re: Lisp interfaces to X
C00500 00090 ∂29-Jan-87 1114 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Me 'n X (ignore if you like)
C00503 00091 ∂29-Jan-87 1114 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU foreign function interfaces
C00505 00092 ∂29-Jan-87 1114 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU X interface
C00510 00093 ∂29-Jan-87 1212 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU foreign function interfaces
C00512 00094 ∂30-Jan-87 1325 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Lisp interfaces to X
C00514 00095 ∂31-Jan-87 0956 meltsner@athena.MIT.EDU Vendors and X + LISP
C00516 00096 ∂04-Feb-87 1547 Ehrlich@YUKON.SCRC.Symbolics.COM Window Systems Survey
C00521 00097 ∂06-Feb-87 1311 BATALI@SPAR-20.ARPA please add me
C00522 00098 ∂11-Feb-87 1658 DON%atc.bendix.com@RELAY.CS.NET Bulletin board subscription
C00524 00099 ∂13-Feb-87 0636 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU X atoms, a poll
C00528 00100 ∂13-Feb-87 0808 FAHLMAN@C.CS.CMU.EDU X atoms, a poll
C00533 00101 ∂13-Feb-87 0859 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU X atoms, a poll
C00537 00102 ∂13-Feb-87 0959 RAM@C.CS.CMU.EDU X atoms, a poll
C00540 00103 ∂13-Feb-87 1221 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU underscores
C00542 00104 ∂13-Feb-87 1228 FAHLMAN@C.CS.CMU.EDU X atoms, a poll
C00547 00105 ∂13-Feb-87 1249 Moon@STONY-BROOK.SCRC.Symbolics.COM X atoms, a poll
C00549 00106 ∂13-Feb-87 1345 RAM@C.CS.CMU.EDU underscores
C00552 00107 ∂19-Feb-87 1401 SPIRKOV%PLU@ames-io.ARPA please add me to the mailing list.
C00553 00108 ∂20-Feb-87 1555 TAYLOR%PLU@ames-io.ARPA CW Standard Status
C00555 00109 ∂20-Feb-87 1944 FAHLMAN@C.CS.CMU.EDU CW Standard Status
C00559 00110 ∂20-Feb-87 2354 edsel!bhopal!jonl@navajo.stanford.edu CW Standard Status
C00563 00111 ∂21-Feb-87 0833 CS.WERTH@R20.UTEXAS.EDU please add me to the mailing list
C00564 00112 ∂21-Feb-87 1523 RICHER@SUMEX-AIM.STANFORD.EDU CL-WINDOWS standards
C00572 00113 ∂22-Feb-87 0846 FAHLMAN@C.CS.CMU.EDU CL-WINDOWS standards
C00581 00114 ∂22-Feb-87 1741 FAHLMAN@C.CS.CMU.EDU CW Standard Status
C00584 00115 ∂23-Feb-87 0333 mcvax!inria!inria.inria.fr!devin@seismo.CSS.GOV change me
C00586 00116 ∂23-Feb-87 0813 dcmartin@ingres.berkeley.edu X/Common LISP interface
C00589 00117 ∂23-Feb-87 1305 RICHER@SUMEX-AIM.STANFORD.EDU Re: X/Common LISP interface
C00592 00118 ∂23-Feb-87 1852 mqb@cive.ri.cmu.edu Re: X/Common LISP interface
C00594 00119 ∂24-Feb-87 1733 wanginst!ulowell!grinstei@harvard.harvard.edu Re: X/Common LISP interface
C00596 00120 ∂25-Feb-87 1637 rochester!tropix!dls@seismo.CSS.GOV Re: CW Standard Status
C00604 00121 ∂02-Mar-87 2124 WELCH%OSU-20@ohio-state.ARPA X in CL
C00606 00122 ∂09-Mar-87 1201 KASTNER@IBM.COM
C00607 00123 ∂10-Mar-87 1215 pierce@rd1632 Common Lisp Windows
C00609 00124 ∂10-Mar-87 1221 AKBARI@CS.COLUMBIA.EDU please add me
C00611 00125 ∂12-Mar-87 1405 dcmartin@ingres.Berkeley.EDU X/Common LISP interface
C00613 00126 ∂21-Mar-87 1733 RICHER@SUMEX-AIM.STANFORD.EDU [gabriel@vaxa.isi.edu (Gabriel Robins): Re: ISI grapher]
C00622 00127 ∂02-Apr-87 1533 MMcM@STONY-BROOK.SCRC.Symbolics.COM Window systems standardization
C00637 00128 ∂03-Apr-87 0603 @ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU CLX proposal: cover message
C00643 00129 ∂03-Apr-87 0606 @ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU CLX: a proposal
C00736 00130 ∂03-Apr-87 0632 AVELLIS%IBACSATA.BITNET@forsythe.stanford.edu subscription
C00738 00131 ∂03-Apr-87 0839 dcmartin@ingres.berkeley.edu X/Common LISP library package (Beta release)
C00741 00132 ∂09-Apr-87 0703 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU revisions to CLX proposal
C00746 00133 ∂09-Apr-87 0745 RAM@C.CS.CMU.EDU revisions to CLX proposal
C00748 00134 ∂09-Apr-87 0803 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU plist revisions to CLX proposal
C00750 00135 ∂09-Apr-87 0843 FAHLMAN@C.CS.CMU.EDU plist revisions to CLX proposal
C00753 00136 ∂09-Apr-87 1135 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: what package is the CLX stuff in?
C00755 00137 ∂09-Apr-87 1213 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU plist revisions to CLX proposal
C00758 00138 ∂09-Apr-87 1354 FAHLMAN@C.CS.CMU.EDU plist revisions to CLX proposal
C00764 00139 ∂09-Apr-87 1443 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU plist revisions to CLX proposal
C00769 00140 ∂09-Apr-87 1701 FAHLMAN@C.CS.CMU.EDU plist revisions to CLX proposal
C00773 00141 ∂09-Apr-87 2327 unido!gmdzi!jc@seismo.CSS.GOV plist revisions to CLX proposal
C00777 00142 ∂10-Apr-87 1055 DALY@IBM.COM passing structures to be destructively modified
C00778 00143 ∂10-Apr-87 1821 ibuki!weaver@labrea.stanford.edu Berkeley CL X windows 10 available for KCL
C00780 00144 ∂11-Apr-87 0826 RAM@C.CS.CMU.EDU plist revisions to CLX proposal
C00784 00145 ∂12-Apr-87 1011 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU latest X11 protocol document
C00786 00146 ∂12-Apr-87 1308 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU plist revisions to CLX proposal
C00794 00147 ∂12-Apr-87 1313 Gumby%AI.AI.MIT.EDU.#Chaos@XX.LCS.MIT.EDU passing structures to be destructively modified
C00796 00148 ∂13-Apr-87 0852 rochester!tropix!dls@seismo.CSS.GOV Re: passing structures to be destructively modified
C00799 00149 ∂13-Apr-87 1305 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: passing structures to be destructively modified
C00803 00150 ∂13-Apr-87 1354 Oren%Tilde%ti-csl.csnet@RELAY.CS.NET CLX With-Display speed hack
C00808 00151 ∂13-Apr-87 1427 carter%silicon@cs.utah.edu de-subscription
C00809 00152 ∂13-Apr-87 2109 janson@ATHENA.MIT.EDU common lisp X interface
C00811 00153 ∂14-Apr-87 0826 FAHLMAN@C.CS.CMU.EDU common lisp X interface
C00813 00154 ∂14-Apr-87 0906 RAM@C.CS.CMU.EDU XCL comments
C00822 00155 ∂14-Apr-87 1131 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU CLX With-Display speed hack
C00832 00156 ∂14-Apr-87 1351 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU XCL [sic] comments
C00844 00157 ∂14-Apr-87 1410 burdorf@rand-unix.ARPA Re: plist revisions to CLX proposal
C00845 00158 ∂14-Apr-87 1611 RAM@C.CS.CMU.EDU XCL [sic] comments
C00855 00159 ∂14-Apr-87 2143 Moon@STONY-BROOK.SCRC.Symbolics.COM plist revisions to CLX proposal
C00862 00160 ∂15-Apr-87 0701 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU keyword args and consing
C00865 00161 ∂15-Apr-87 0734 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU XCL [sic] comments
C00870 00162 ∂15-Apr-87 0809 larus@paris.Berkeley.EDU Re: keyword args and consing
C00872 00163 ∂15-Apr-87 0831 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU plist revisions to CLX proposal
C00878 00164 ∂15-Apr-87 0834 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU another try at CLX "lots of result values"
C00888 00165 ∂15-Apr-87 0901 FAHLMAN@C.CS.CMU.EDU keyword args and consing
C00893 00166 ∂15-Apr-87 1038 Moon@STONY-BROOK.SCRC.Symbolics.COM keyword args and consing
C00898 00167 ∂15-Apr-87 1116 RAM@C.CS.CMU.EDU keyword args and consing
C00900 00168 ∂15-Apr-87 1629 MMcM@YUKON.SCRC.Symbolics.COM XCL [sic] comments
C00905 00169 ∂15-Apr-87 1854 edsel!bhopal!jonl@navajo.stanford.edu keyword args and consing
C00907 00170 ∂15-Apr-87 1936 FAHLMAN@C.CS.CMU.EDU Consing &key args
C00908 00171 ∂16-Apr-87 0857 Oren%Tilde%ti-csl.csnet@RELAY.CS.NET Re: plist revisions to CLX proposal
C00911 00172 ∂16-Apr-87 0944 lowry%bizet.DEC@decwrl.DEC.COM X interface
C00914 00173 ∂16-Apr-87 1041 ibuki!weaver@labrea.stanford.edu Re: keyword args and consing
C00916 00174 ∂17-Apr-87 0820 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU minor correction to CLX event-case
C00918 00175 ∂22-Apr-87 0551 RWS@ZERMATT.LCS.MIT.EDU WITH-GC semantics in CLX
C00920 00176 ∂22-Apr-87 2012 Moon@STONY-BROOK.SCRC.Symbolics.COM another try at CLX "lots of result values"
C00929 ENDMK
C⊗;
Introduction
Welcome to the Common Lisp Window Subgroup.
In order to mail to this group, send to the address:
CL-Windows@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLWIND.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Windows-request@su-ai.arpa
Here is a list of the people who are currently on the mailing list:
Person Affiliation Net Address
Kent Pitman MIT kmp@mc
Dick Gabriel Stanford/Lucid rpg@sail
Carl Hewitt MIT hewitt-windows@mc
Don Allen BBN allen@bbnf
Dan Oldman Data General not established
Larry Stabile Apollo not established
Tom Kaczuarek ISI kaczuarek@isi
Dave Matthews HP matthews.hplabs@csnet-relay (I hope)
Dan Stenger TI stenger.ti-csl@csnet-relay
Gary Brown DEC gbrown@dec-marlboro
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Thomas Gruber Univ. of Mass. gruber.UMass-CS@csnet-relay
The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.
Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete.
∂23-Sep-84 1610 RPG Introduction
To: cl-windows@SU-AI.ARPA
Welcome to the Common Lisp Window Subgroup.
In order to mail to this group, send to the address:
CL-Windows@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLWIND.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Windows-request@su-ai.arpa
Here is a list of the people who are currently on the mailing list:
Person Affiliation Net Address
Kent Pitman MIT kmp@mc
Dick Gabriel Stanford/Lucid rpg@sail
Carl Hewitt MIT hewitt-windows@mc
Don Allen BBN allen@bbnf
Dan Oldman Data General not established
Larry Stabile Apollo not established
Tom Kaczuarek ISI kaczuarek@isi
Dave Matthews HP matthews.hplabs@csnet-relay (I hope)
Dan Stenger TI stenger.ti-csl@csnet-relay
Gary Brown DEC gbrown@dec-marlboro
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Thomas Gruber Univ. of Mass. gruber.UMass-CS@csnet-relay
The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.
Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete.
∂02-Oct-84 1311 RPG Chairman
To: cl-windows@SU-AI.ARPA
Now that we've basically got most everyone who is interested on the mailing
list, let's pick a chairman. I suggest that people volunteer for chairman.
The duties are to keep the discussion going, to gather proposals and review
them, and to otherwise administer the needs of the mailing list. I will
retain the duties of maintaining the list itself and the archives, but
otherwise the chairman will be running the show.
Any takers?
-rpg-
∂13-Oct-84 1440 RPG Chairman
To: cl-windows@SU-AI.ARPA
No one has been nominated as chairman of the Windows subgroup. I
suggest Howard Cannon of Symbolics. If he is willing, and no one else
volunteers, he will become chairman. Please respond by October 24. At the
end of this month I want to see some ideas and proposals coming in on this
mailing list.
-rpg-
∂25-Oct-84 0944 FILE-SERVER%WHITE.SWW.Symbolics@SCRC-RIVERSIDE.ARPA Chairman
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 25 Oct 84 09:43:40 PDT
Received: from SWW-WHITE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 94510; Tue 23-Oct-84 23:01:25-EDT
Date: Tue, 23 Oct 84 20:06 PDT
From: hic%SWW-WHITE@SCRC-RIVERSIDE.ARPA
Sender: FILE-SERVER%SWW-WHITE@SCRC-RIVERSIDE.ARPA
Subject: Chairman
To: RPG@SU-AI.ARPA, cl-windows@SU-AI.ARPA
In-reply-to: The message of 13 Oct 84 14:40-PDT from Dick Gabriel <RPG at SU-AI>
Received: from SCRC-STONY-BROOK by SWW-WHITE via CHAOS with CHAOS-MAIL id 47648; Sat 13-Oct-84 15:37:52-PDT
Received: from MIT-MC by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 107864; Sat 13-Oct-84 18:32:38-EDT
Date: 13 Oct 84 1440 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Chairman
To: cl-windows@SU-AI.ARPA
No one has been nominated as chairman of the Windows subgroup. I
suggest Howard Cannon of Symbolics. If he is willing, and no one else
volunteers, he will become chairman. Please respond by October 24. At the
end of this month I want to see some ideas and proposals coming in on this
mailing list.
-rpg-
Ah, I see I received this message. I was worried that this mail wasn't
getting through, or was stuck at MC, or...
In any case, I respectfully decline the offer, not because I don't want
to do it but because of extensive traveling I don't feel I could be
reliable enough. I do hope to participate actively, though.
I suggest that DDYER would do a fine job as chairman.
--Howard
∂27-Oct-84 2148 RPG Hello folks
To: cl-windows@SU-AI.ARPA
We now have a chairman of the windows subgroup: Dave Dyer of Symbolics. I
think he will make an excellent chairman. For your information I am
including the current members of the mailing list.
I will now let Dave Dyer take over responsibility for the discussion.
David Matthews HP "hpfclp!windows%hplabs"@csnet-relay,
Jerry Boetje DEC Boetje@dec-hudson
John Foderaro Berkeley jkf@ucbmike.arpa
Steve Muchnick SUN "ucbvax!sun!muchnick"@berkeley
Howard Cannon Symbolics "hic%scrc"@mc
Dave Dyer Symbolics ddyer@isib
Skef Wholey CMU Wholey@cmuc
Richard Zippel MIT rz@mc
Ron MacLachlan CMU RAM@cmu-cs-c
John Peterson Univ of Utah jw-peterson@utah-20
Kent Pitman MIT kmp@mc
Dick Gabriel Stanford/Lucid rpg@sail
Carl Hewitt MIT hewitt-windows@mc
Don Allen BBN allen@bbnf
Dan Oldman Data General not established
Larry Stabile Apollo not established
Tom Kaczmarek ISI kaczmarek@isi
Dan Stenger TI stenger.ti-csl@csnet-relay
Gary Brown DEC brown@dec-hudson
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Thomas Gruber Univ. of Mass. gruber.UMass-CS@csnet-relay
Ron Fischer Rutgers fischer@rutgers
Dario Giuse CMU dzg@cmu-cs-spice
Neal Feinberg Symbolics feinberg@scrc-stony-brook
∂28-Oct-84 1054 DDYER@USC-ISIB.ARPA Initial questions
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 28 Oct 84 10:53:57 PST
Date: 28 Oct 1984 10:52:38 PST
Subject: Initial questions
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
Ok, since I have no idea what I'm supposed to do, I'll
just do what comes naturally. What is the scope of
this discussion? These questions come to mind:
What kinds of window hardware are we talking about? Plain
glass ttys? Bitmapped? Vector? Color?
What implementation technology? Particularly, will we use
whatever the CL standard for objects becomes, or structures.
Fonts? Text formatting? What is the boundary between
this mailing list and what "graphics" will discuss.
What about pointing devices?
-------
∂29-Oct-84 0917 DDYER@USC-ISIB.ARPA Initial Answer
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 29 Oct 84 09:17:19 PST
Date: 29 Oct 1984 09:12:53 PST
Subject: Initial Answer
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
[ Editors Note: Since this reply came to me rather than the mailing list,
I am reminded of the perpetual question; "To Digest or not to Digest"
For now, I will package any replies that come directly to me, and send
them to the mailing list from time to time. Messages sent to
cl-windows@su-ai will continue to be redistributed immediately.
DDyer@isib]
Return-Path: <KACZMAREK@USC-ISIF.ARPA>
Date: 29 Oct 1984 07:47:00 PST
Subject: Re: Initial questions
From: Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>
Regarding interaction with the graphics group, I think we ought to try to
build on top of what they supply. I suspect that there is enough cross-
membership to insure that we have sufficient influence. (I haven't compared
the mailing lists so I could be wrong about that.)
[ddyer: I tend to look at it the other way; Graphics is an additional
behavior of windows, and graphics capabilities will be built out of
whatever we supply.]
As far as display hardware goes there seems to be two interesting classes--
"graphics" and glass ttys. Color is an orthogonal issue, isn't it?
Number of bit planes for black and white graphics falls in this same
category. Both graphic devices and ttys come in black and white (with
intensity levels) or color. Graceful degradation seems to be the
appropriate way to handle these issues. I believe the graphics people
having been looking at this issue for some time and have solutions for this
problem.
I would guess that if the graphics group does its job well, vector versus
bitmapped graphics should not be an issue. The resolution of the graphics
may be an issue however. Low resolution graphics devices seem a lot like
glass ttys as far as windows go. Storage vector graphics hardware (ala
old Tektronix stuff) does not lend itself to the kind of interaction one
expects from a window system so I think we can eliminate it. I believe the
graphics group also should make pointing devices less of a problem since
graphics standards have abstracted actions like "picking." I believe that
complex mouse buttoning will still be something of a problem.
Structures versus objects seems to be a difficult decision. Perhaps having
to wait for a object standard will be the best argument for structures.
Conceptually, objects are nice for the kind of interactions that occur in
the window world. Is efficiency an issue here? Object-oriented
implementations seems to rely on interpretation rather than compilation.
Is that because nobody has done it differently or is it too hard? Or
impossible? Or am I wrong about that?
[ddyer: flavors are compiled]
Tom
-------
-------
∂29-Oct-84 1045 boetje@DEC-HUDSON some initial answers(?)
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Oct 84 10:43:09 PST
Date: Mon, 29 Oct 84 13:39:39 EST
From: boetje@DEC-HUDSON
Subject: some initial answers(?)
To: cl-windows@su-ai.arpa
Ok, it's Monday morning and I'm ready to take on windows. This note is in
direct reply to Dave Dyer's set of questions over the weekend.
Let's take the terminology question first. I have a strong feeling that we
need to get this handled before much else can happen. One of the major
difficulties in this area is that there seem to be two different views of what
the term "window" refers to. Most everyone working on bitmapped screens these
days calls the funny rectangular areas (with borders and labels, in which you
can put text or draw lines) windows. The graphics community uses "window" in a
very different way. A window is really a way to specify a set of coordinate
transformations and a set of bounding coordinates for clipping purposes. You
can't ever see a graphics window. It takes a viewport to make that happen.
Viewports are potentially viewable objects. But of course in that graphics
world, there isn't a firm concept of borders and labels.
I will put forth the following radical suggestion: the graphics folks were
here first, so their terminology should take precedence. Windows and viewports
are strictly defined in the world of real graphics. A window is a set of
limiting coordinates (x-y min and max values) in some arbitrary system
(usually the coordinate system of the data values to be plotted). This defines
the aspect ratio of the eventual display of data. A viewport is another set of
limiting coordinates which are used to map the data plotted in coordinates of
the window to a displayable rectangle (this provides for clipping,
magnification, and transformation to the physical device).So we won't do
windows (sorry about the marketing slogan). We need to call those funny
rectangles on the screen something else.
Before I unveil my terms, let me introduce a concept into this arena. In both
the graphics world and whatever-we-call-the-current-thing world, there is the
idea of a displayable object. In the graphics world, viewports can be
displayable objects (when they map things from NDC space for example). They
can also be previously created "pictures" which can be used to make composite
images (for example, the symbol for a NAND gate in a CAD system). The common
term for this object is "segment". Segments can be replicated and scaled ad
nauseum to make a larger displayable object. The graphics world thus has a
model of composition by using displayable objects as well as basic line
drawing primitives.
In the bitmapped world, "windows" are considered displayable objects. In the
case of Symbolics, they also provide the idea of decomposition of their window
into "panes" (which can be treated as individual windows for many purposes).
Another way of looking at their system is that they treat their "window" as a
displayable object which can be composed of other windows. Their composition
process also involves a particular contraint system on the interaction between
the parts of a composed displayable object (resize one and the others adjust).
With all that said, I now introduce my own terms (liberally borrowed from
unnamed sources):
1. Virtual Display. This is what most folks think of as a "window" or perhaps
a bitmap (depending on whether it's visible or not). You may see it (touch it
and taste it if it's late enough at night) on the screen. It's a rectangular
area which may be made to appear on a physical display (hence the term virtual
display) which can have a border, a label, etc. Primitive operations can put
information into the display (like writing characters or drawing lines). If
they are not currently visible on the physical display, their current state is
kept and modified by primitive operations.
They can also be composed of other virtual displays with appropriate
constraints at the whim of the implemectation. It may or may not be on the
physical display and it may or may not be hidden obscured by other visible
displays). It can function as an I/O device for CL streams. And if you're into
the graphics side of the world, viewports map directly into the non-border
portion of virtual displays.
2. Windows and viewports retain (and will only be used for describing) their
traditional meanings in the world of graphics (which among other things means
that windows and viewports operate in coordinate systems other than that of
the physical display device).
3. Displayable object. Well, I gave the sense of it above. If we want to
strictly define it for CL, then we'll need to do some work on it. I'm inclined
to leave it alone for now and just use it by way of introducing concepts of
composition. We'd need to be very closely tied to the graphics folks if we
want to define it in the language.
Ok, enough on terms. Hardware... hmm... Curiously, the most limiting hardware
is the vector drawing equipment, because it's hard to change once you've put
it on the screen. My thought is that we should at least define operations that
can be done on a cell-oriented screen. We can define optional capabilities for
displays, but that gets us into the serious business of specifying how the
user program determines the capabilities that can be used on the runtime
device and what the error mechanism is for operations that can't be supported
on the current device. The GKS graphics folks have done this and the inquiry
functions outnumber the primitive operations.
On the software implementation, we should go for the least disruptive and
commonly implemented features (GCLISP has some nice display stuff on a small
machine). I think this means structures, not objects. We might want to define
an optional object interface to the displays, but I think we need the simple
level as well. Also, I don't want to wait around for the religious wars over
objects. We'll have enough of our own...
Fonts, et al. Ok, we need some optional ways to specify font information and
it's not clear that font bits are the best way to go. VAX LISP would probably
have a difficult time handling font information in strings (efficient strings
for us are one byte per character). Font information should be an ignoreable
parameter (VT200's don't do well when commanded to go into Times Roman).
Having a function that computes the actual screen size of a string in a
specified font is a must.
Text formatting. We need text primitives to write, erase and insert
characters. But I'm not anxious to get into the business of putting Scribe
into CL. But there should be enough functionality for the cottage industries
to write a formatting system on top of the CL primitives.
Boundary between this group and graphics. Ok, I've got a foot in both, so I'll
jump in. We should stick to the ideas of virtual displays and composition of
virtual displays. They should always operate in the coordinate system of the
device. The graphics world should get windows, viewports and segments and
operate in non-device coordinates. Our major interface then becomes a mapping
of viewport to virtual display with the graphics side worrying about the
scaling and clipping into the device (virtual display) coordinates.
Last topic for now... pointing devices. hmmm. They're needed for two purposes,
at least. One is to do operations on entire virtual displays (like popping
them to the surface). They other is to indicate a point or segment within a
virtual display. These operations can be handled with mouses and tablets and
can be simulated with cursor keys. We have to be careful not to get into the
business of defining a user interface to CL (pointing at a label brings a
display to the surface). But it would be nice to have some simple functions to
let users roll their own.
Indicating a point or segment is a bit more interesting and gets us involved
with the graphics group. Points within a virtual display need to be returned
in some coordinate system. Most bitmap systems give back a point in raster
coordinates. That's probably limiting. The graphics world likes them returned
in the original coordinates used to draw the picture. And picking graphics
segments has a close counterpart in defining/selecting a sensitive region.
Topic for next time.
Oh yes, color. Pick and stick to one of the international standards. There's
RGB (red, green, blue) and HLS (hue, lightness and saturation). Any of you
VideoText folks probably have yet another way. I have no real preference (just
a minor leaning to HLS) but I haven't figured out if I should grind an ax on
this or not. Issue deferred...
Jerry
∂30-Oct-84 0711 dzg@cmu-cs-spice.arpa Terminology, etc.
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 30 Oct 84 07:10:20 PST
Date: Tuesday 30 October 1984 09:33:00am-EST
From: dzg@CMU-CS-SPICE.ARPA
To: cl-windows@su-ai.arpa
Subject: Terminology, etc.
Message-ID: <0.0.dzg>
I mostly agree with Jerry Boetje. Let's use "window" for a set of bounding
coordinates; the confusion in the bitmap world is hopeless anyway. As an
example, on the Perq a 'viewport' is a rectangular portion of a display, and
a 'window' is essentially a viewport embellished with borders and a
'title'; on the Symbolics, a 'window' is essentially a viewport that may or
may not have borders and a 'label' (title).
I have a little problem with the term "segment", just because it is so
overloaded. I would try and suggest "symbol", a' la Newman & Sproull, just
because it's nice to talk about a symbol and a symbol instance. I realize,
though, that the word "symbol" is also overloaded...
One related question is transformations: can you only specify a
transformation (rotation, scale, offset) for symbols|segments, or can you
transform any graphical object in place? Do you want to be able to say
"This is an arc of a circle, center and radius such and such, and by the
way it is scaled up 3.2 and rotated pi radians"? Or do you always have to
wrap the arc in a symbol|segment to achieve the same effect?
I also agree that we should use the universally available Structures for
the software implementation, given that no universally accepted (or
implemented!) notion of object seems to be around the corner. The BIG
problem, here, is that if you are not very careful your structures turn out
to be a "display list" that the system maintains, and so you have to
duplicate them all to put the interesting stuff you want to deal with. One
of the ideas I am trying to work on is to SHARE your data structures with
the system, so that you can have all the nice slots you want in there that
are not graphical at all, while the system can store all its internal cute
optimization things in it. This is unfortunately difficult to do with
structures a' la DefStruct, since the slots are defined once and for all.
An object system would be much nicer, since the system can define all its
nasty things and you never need to know about them.
Fonts: the "best approximation" paradigm should apply. My approach would be
to have a very generic font definition (family name, face, size, rotation)
which would be mapped into whatever the system provides. Font names are
totally hopeless (What's a CPT10? Is it 10 points or 10 pixels? Or is it
the 10th font in the file CPT? And what's a CPT anyway?), so I think one
would end up having a device-dependent mapping between an "abstract font"
and whatever the system provides. The mapping would be very dull on the
VT200, for instance, but one should use an abstract specification
nonetheless.
I very strongly oppose any notion of text formatting. Only the very minimal
level of support, including obviously the ability to get device-dependent
font information (IN WORLD COORDINATES, not in device coordinates!), should
be present. More complex text formatting is A) highly dependent on personal
taste, and B) extremely difficult to do right for sophisticated
applications. I certainly don't want a window system at this level to have
to deal with kerning and italic corrections.
- Dario -
∂31-Oct-84 0723 STENGER%ti-csl.csnet@csnet-relay.arpa re: inital answers
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 31 Oct 84 07:23:51 PST
Received: from ti-csl by csnet-relay.csnet id ad00735; 31 Oct 84 10:18 EST
Date: 31 Oct 1984 0625-CST
From: Dan Stenger <STENGER%ti-csl.csnet@csnet-relay.arpa>
Subject: re: inital answers
To: cl-windows%su-ai.arpa@csnet-relay.arpa
Received: from csl60 by ti-csl; Wed, 31 Oct 84 09:13 CST
On terminology:
I agree with Jerry Boetje's proposal on the terminology that we should use.
We should settle on something so that we all understand each other. The
main problem I see with this is that the terms "windows" and "panes" are
well established in the Lisp community and we may just cause confusion.
On bounds of this group:
I am also in the graphics group. My view is that we should limit the
efforts of the windows group to virtual displays and other things that
need to work in device coordinates. The graphics group should handle
what is shown in the virtual displays.
On the software implementation:
I agree that structures are the way to go. Some implementations may not
want the object oriented programming system but may want windows. Also
the wait may just put us too far behind.
On display hardware:
It would be nice if what we come up with is compatible with vector refresh
and storage tube hardware but I do not think that we should concern ourselves
with it. The types of hardware which we do need to address are black/white
and color bitmaped terminals, and text only terminals.
In general I think we should try to design something that is concise, simple,
but very general. It should be implementable on small machines but be easily
extended (not restrictive) for larger machines.
Dan Stenger
-------
∂02-Nov-84 2330 DDYER@USC-ISIB.ARPA Real devices (mainly)
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 2 Nov 84 23:30:41 PST
Date: 2 Nov 1984 23:26:10 PST
Subject: Real devices (mainly)
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
There seems to be consensus that vector displays are outside
our domain. If there are no devotees of vector displays out
out there, I'll consider it official.
I liked "virtual display", but one term isn't a complete glossary.
Several messages have cast a word in favor of supporting ordinary
terminals; but I wonder just how much one can do, especially if
"virtual display" is taken to imply "multiple virtual displays".
In practice, won't terminals be restricted to one or two virtual
displays, all the same width as the screen? I've done quite
a bit of display hacking on ordinary terminals, and found anything
fancier to be aesthtically awful, even if technically possible.
There simply isn't enough real estate to distinguish more than
a few windows, aren't display capabilities to provide margins
and borders, and the devices themselves don't operate fast or
reliably enough to allow manipulation of arbitrary blocks of
characters in a way that is acceptable to users. Shouldn't we
take this ugly bit of reality into account?
I'm not necessarily proposing we punt terminals entirely, but
we should at least consider defining a limited set of primitives
for terminals sufficient for input editing and (maybe) emacs style
editing.
I also have doubts about several mentions of "device coordinates"
as the appropriate substrate for virtual displays. One at least
needs to be able to speak of either "characters" or "pixels", to
accommodate ordinary terminals and bitmaps, but once pixels are
introduced, a whole nest of other problems surface; such as
aspect ratio, variable width and height of fonts, and the variable
size of pixels on different displays.
For a particular display, one could of course tweak things into
the right device coordinates to give the desired effect, but we
are speaking "portable" here, so need to at least address the question
of transmitting the author's intent to foreign systems.
Just to finish on a concrete point, consider Symbolic's color
displays, where the "same size" characters (in device coordinates)
border on unreadable compared to the same text on the B&W screen.
Also, consider that a single pixel height horizontal line on a
noninterlaced screen is fine, but on an interlaced screen it is
probably unacceptable due to excess flicker.
No program that operates in "device" coordinates can ignore facts
of life such as these. We need to strike a balance between providing
access to the raw facts, and hoping programs cope with all the possible
implications, and attempting to abstract intent into our specs and letting
the implementation cope with the ramifications.
-------
∂03-Nov-84 0747 FAHLMAN@CMU-CS-C.ARPA Goals
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Nov 84 07:47:49 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 3 Nov 84 10:47:55-EST
Date: Sat, 3 Nov 1984 10:47 EST
Message-ID: <FAHLMAN.12060631562.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: cl-windows@SU-AI.ARPA
Subject: Goals
In my opinion, the window group is really in the business of developing
one or more optional semi-standards. What I mean by that is that I
don't think that the Common Lisp specification should require any
particular sort of display or window system in order for something to be
called Common Lisp. Display technology is moving pretty fast, and we
wouldn't want to rule out a Common Lisp in a wristwatch or a Common Lisp
running on a brute-force machine with no display of its own.
Furthermore, each machine running Common Lisp will have a few
specialized high-performance tricks available that users will want to
access for the most demanding applications: one machine might have a
hardware font and vector generator, another might have an incredibly
smart rasterop, and so on.
But what we can and should do is to develop one or more clean interfaces
for doing some collection of popular things on certain popular families
of display technologies. Implementors will be encouraged to provide
these standard interfaces on their machines wherever they make sense,
and people developing display-oriented code will then have the option of
writing it using the portable interface, for easy portability across a
class of machines, or of writing it to make the best possible use of a
given machine using whatever tense non-standard mechanisms may be
available.
It seems to me that three families of display device are going to be
important in the near future: 24x80 character terminals with varying
degrees of crude graphics support, high-resolution (at least 600 x
800) monochrome bit-mapped displays with some sort of pointing device,
and high-res bit-mapped displays with color. Rather than ruin the
interface we develop for bit-mapped displays by trying too hard to make
it all work on ASCII terminals, I propose that we define three separate
interfaces:
Level 1: Can be implemented on the majority of ASCII termianls.
Level 2: Assumes bit-mapped graphics, reasonable resolution, and a
pointer.
Level 3: Same as above, but with color.
Software developers can target their software to raw common Lisp or to
any of these levels, depending on the capability they need and the
market they wish to address, or they can go native on a single
machine/system. Maybe levels 2 and 3 can be collapsed into one.
This is set up as a sort of hierarchy, since I am assuming that any
machine providing level 2 support will also provide level 1 support and
so on. But the situation is really not hierarchical -- one might
imagine vector displays as wanting a different kind of interface
altogether.
The most important need right now is to come up with something for level
2, since the vast majority of Common Lisp implementations (not weighted
by number of users) is on machines of this class.
-- Scott
∂04-Nov-84 1816 JW-PETERSON@UTAH-20.ARPA Some responses...
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 4 Nov 84 18:16:37 PST
Date: Sun 4 Nov 84 19:16:54-MST
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Some responses...
To: cl-windows@SU-AI.ARPA
VT100's. The 24x80 terminal may not be dead, but is quickly dying. A
reasonably intelligent bitmapped terminal with a mouse runs around $2K, and
will shortly drop to the VT100 [& clones] price range - this seems like a
good "lowest common denominator" level.
Fonts. The discussion of fonts and formatting brings up an interesting
analogy: When the world migrated from TTY's to CRT's, many programs broke
(or just "looked ugly") because they couldn't deal with lower case input or
output. The same sort of thing appears to be happening again, only this
time things are breaking (or just not looking right) because they can't deal
with multiple fonts - particularly ones with proportional spacing. Having
at least some formatting facilities inherent in the window system (e.g., tab
stops that work correctly with proportional spaced fonts) would make the
programmer's life noticeably easier.
Units of measure. Is anything wrong with measuring things in Pixels? It
makes life much, much simpler (both conceptually and pragmatically) to
define screen coordinates in pixel units. There is nothing very "display
specific" about pixel units of measure, particularly when you consider
"Virtual Displays" are usually of various sizes on the same screen. As long
as we use digital computers, screens will be measured in discrete units -
both graphics and window packages might as well behave the same way.
(An interesting discussion of this is presented in "A Language for Bitmap
Manipulation" by Guibas & Stolfi in the July '82 Transactions on Graphics.)
-------
∂19-Nov-84 0019 DDYER@USC-ISIB.ARPA Proposals and questions
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 19 Nov 84 00:19:31 PST
Date: 19 Nov 1984 00:18:26 PST
Subject: Proposals and questions
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
I like Scott Fahlman's notion of defining two sets
of protocols, one for simple terminals and the other
for rasters. Presumably the terminal protocol would
use characters and lines as its units, while the
raster protocol would use either characters or pixels.
Are there any existing standards we might use as a
starting point? I'm hoping for something more abstract
than the lisp machine window system manual! The first
proposal circulated is likely to become the de facto standard.
In accordance with the above, I suggest the following
framework:
Each virtual display divides the world into three parts,
INSIDE, BORDERS, and OUTSIDE.
INSIDE a virtual display, two protocol sets are defined,
a "character oriented set" and a "raster oriented set".
The character oriented set deals with size, positioning,
font and other characteristics of characters. The
raster oriented protocol also addresses characters,
but also any other graphics and display primitives.
It is permitted for an implementation to implement only
the character oriented protocol.
OUTSIDE a virtual display, protocols deal with its
size, position, visibility and so on with respect to
its superior.
I'm not sure how to encapsulate the notion of BORDERS
succinctly. The best I can think of at the moment
is that borders are a specialization of the more general
notion of "clipping region"; that a window is defined
by a clipped region within its superior, and may
in turn define an inferior clipping region.
ANOTHER NEW QUESTION
I'm personally a little worried by the consensus to implement
virtual displays using structures. By way of bringing my
concerns to the surface, I'll pose a question:
How much user extensibility to window system behavior will be
expected/permitted, and how will the data structure and procedural
hooks for that extensibility be supported?
I think it is important that extensibility be a goal, and that
"extended" windows (oops! virtual displays!) be as well integrated
and as efficiently implemented as the system's supplied windows.
I know how to do this in an object oriented window system. Tell me
how you'll do it in a structure based system.
-------
∂19-Nov-84 2035 WHOLEY@CMU-CS-C.ARPA Proposals and questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Nov 84 20:34:25 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 19 Nov 84 23:33:14-EST
Date: Mon, 19 Nov 1984 23:33 EST
Message-ID: <WHOLEY.12064965182.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Cl-Windows@SU-AI.ARPA
CC: Dave Dyer <DDYER@USC-ISIB.ARPA>
Subject: Proposals and questions
In-reply-to: Msg of 19 Nov 1984 03:18-EST from Dave Dyer <DDYER at USC-ISIB.ARPA>
Here are some of my thoughts on "virtual displays," both their specification
and their implementation (via structures).
There are (currently) about three coarse levels in virtual display fanciness
that a virtual display system should try to support:
Glass TTY with at least an addressable cursor (e.g. ADM-3A)
"Smart" CRT terminal (e.g. Concept-100, VT-200)
Bitmapped displays
I believe that any virtual display should support all operations (we have yet
to decide on the operations, but my point is that something like DELETE-CHAR
can be performed on any of the above, albeit with different performance). Non-
bitmapped terminals could be treated as having 24 by 80 (or whatever) pixels,
and a 1 by 1 font.
The redisplay module of a text editor will want to use different screen update
algorithms depending on the sort of virtual display it is writing to. Thus, a
virtual display should be able to provide information about the relative
efficiency of its operations. At the very least, a programmer should be able
to find out in which of the three categories listed above a virtual display
belongs. The editor's redisplay algorithm can then be tuned to the particular
output device. The casual programmer could of course opt to ignore this extra
information. The virtual display machinery could do all kinds of redisplay
optimization itself, but I believe that certain decisions are best made in the
client program.
Thus, the different "protocols" that Scott suggests would be kept at a level
below the virtual display operations, but programmers that wanted to could
easily figure out useful things about the implementation of a particular
virtual display.
We at CMU have had a good deal of success implementing streams with structures,
which leads me to believe that they'll be sufficient for implementing virtual
displays as well. Our stream structures store both functions ("methods") and
data ("instance variables"). Common Lisp DEFSTRUCT provides inheritance
through the :INCLUDE option, which makes streams (somewhat) easily extensible.
I realize that this system is less flexible than one built on flavors (or any
other real object-oriented programming system), but it is highly portable, and
gives you 90% of the extensibility you'd ever want.
Thus, we might define a virtual display like this:
(defstruct vd
"The root Virtual Display structure."
;; Methods:
display-char ; Method for Display-char
display-string ; Method for Display-string
delete-char ; Method for Delete-Char
...
;; Instance variables:
width ; Width in pixels
height ; Height in pixels
cursor-row ; Row that the cursor's on
cursor-column ; Column the cursor's on
...)
(defun display-char (vd char)
"Displays the Char at the current cursor position of the VD,
moving the cursor appropriately."
(funcall (vd-display-char vd) char))
...
Then we could define a particular kind of virtual display like this:
(defstruct (c100-vd
(:include vd
(display-char c100-vd-display-char)
(display-string c100-vd-display-string)
...))
"The VD for Concept-100 terminals."
;; Additional instance variables:
stream)
(defun c100-vd-display-char (vd char)
(write-char (c100-vd-stream vd) char)
(cond ((char= char #\newline)
(setf (vd-cursor-column vd) 0)
(incf (vd-cursor-row vd)))
(t
(incf (vd-cursor-column vd)))))
...
That's just an example of the sort of thing one can do, and none of the
particular operations should be taken as suggestions for how a virtual display
should work.
Yes, it's more verbose than flavors, but it is portable and perhaps more
efficient than a flavor-based system would be. Such a system CAN be extended
by the user. Do you still think we'd be too constrained by implementing a
virtual display system with structures?
--Skef
∂19-Nov-84 2220 FAHLMAN@CMU-CS-C.ARPA Proposals and questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Nov 84 22:17:38 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 20 Nov 84 01:16:25-EST
Date: Tue, 20 Nov 1984 01:16 EST
Message-ID: <FAHLMAN.12064983964.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Cl-Windows@SU-AI.ARPA
Subject: Proposals and questions
In-reply-to: Msg of 19 Nov 1984 23:33-EST from Skef Wholey <Wholey>
I agree with much of what Skef Wholey says -- especially the part about
being able to find out which class of display device you have -- but I
don't think I agree that "any virtual display should support all
operations". The problem is that there are some things you want to do
on a bitmap that just have no counterpart on a 24x80 ASCII terminal
(smart or not). If we throw all of these things out, we get an interface
for bit-mapped displays that is less powerful than it should be, which
means that more users will write their code using non-standard calls to
get at the display's real power.
Probably the right move is to make the operations for the feeble
displays a subset of those available on the more powerful ones. In some
cases, we might want the operations for more powerful displays to
recognize additional keywords (such as :COLOR). We should try to keep
the number of distinct levels fairly small, however.
On the issue of whether to use objects, I think that we cannot define an
object-orineted interface until the Common Lisp community settles on
some particular object-oriented system as being required on all
implementations (though other object systems might co-exist with this).
I don't expect to see this any time soon -- if a standard is to emerge
at all, it will only be AFTER people have had a chance to play with
portable Flavors and Loops and assorted other things and decide what
they like. I think that we can define a reasonable set of
somewhat-extensible interfaces in a portable non-flavorish way; if we
have to sacrifice some extensibility, that's better than having no
common window interface at all.
-- Scott
∂20-Nov-84 0736 boetje@DEC-HUDSON documenting implementations
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 20 Nov 84 07:35:44 PST
Date: Tue, 20 Nov 84 10:36:01 EST
From: boetje@DEC-HUDSON
Subject: documenting implementations
To: cl-windows@su-ai.arpa
I think the discussion of structures vs object implementation is getting a
little off track. The issues (it seems to me) revolve around the form of the
creation, accessing and setting functions for virtual displays and the method
by which the user can extend the functionality of the virtual display system
Let me address some high level considerations of each issue.
When I say that I prefer a structure implementation for the CL standard, I'm
not saying that I intend that the DEFSTRUCT for various things be defined in
the standard. My intention is that we document and standardize creation,
accessing and setting functions that look like
(setq display-1 (make-virtual-display ...))
(virtual-display-label display-1)
(setf (virtual-display-label display-1) ...)
as opposed to instancing of objects and sending messages to the instances. I
think that under no circumstances should we document a particular DEFSTRUCT
implementation and require all Common LISPs to have this. I think that the
only reason to do this (and it's part of the example Skef gives) is to allow
users to support output devices not explicitly supported by the vendor. This
will get us rapidly down a rat hole of terminal support issues. Support of
"non-vendor" terminals should be an issue for the vendor to address in
whatever way is most efficient on his system. On the other hand, functions
such as SET-CURSOR-POSITION should exist in all the CL implementations and do
the right thing on all supported terminals. If the vendor provides an
implementation dependent way to define support for other terminals, then the
positioning function will do the right thing on these other terminals as well.
Extending the capabilities of operations on virtual displays is a real issue.
On the other hand, it's not clear that we have to address this right now. I
propose that we investigate defining a fairly "complete" range of
functionality which assumes the availability of a nice (color, bitmapped)
display and then look at subsetting this functionality to cell-oriented
terminals. A part of this may be defining a number of inquiry functions which
let the program tailor itself to the capabilities of the run-time device. This
means that we're likely to end up in the same place as the GKS standard which
has more inquiry functions than all the other kinds of function combined.
We can probably have some high level inquiry functions that let the user know
the general category of device (bitmapped, color, vector, cell, etc). Each
category would have a certain level of functionality that's required (by the
standard) for that device and a certain set that's optional and up to the
implementation (eg, narrow virtual displays on a VT100).
∂20-Nov-84 0850 WHOLEY@CMU-CS-C.ARPA Virtual Displays
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Nov 84 08:49:57 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Tue 20 Nov 84 11:48:43-EST
Date: Tue, 20 Nov 1984 11:48 EST
Message-ID: <WHOLEY.12065099060.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: CL-Windows@SU-AI.ARPA
Subject: Virtual Displays
From: Scott E. Fahlman <Fahlman>
I don't think I agree that "any virtual display should support all
operations". The problem is that there are some things you want to do
on a bitmap that just have no counterpart on a 24x80 ASCII terminal
(smart or not). If we throw all of these things out, we get an interface
for bit-mapped displays that is less powerful than it should be, which
means that more users will write their code using non-standard calls to
get at the display's real power.
I believe that the sorts of things you're talking about are in the domain of
CL-Graphics. I could be wrong. Could you give me an example of such
operations? I have a feeling that either they should be hidden by something
very high level (e.g. HALFTONE-RECTANGLE could really halftone a portion of a
raster display, but put a portion of a Concept-100's screen into half-bright
mode), or that they can be implemented by mashing vanilla CRT's into 24x80
raster displays using 1x1 fonts (MOVE-RECTANGLE could do a BITBLT on a raster
display, but actually copy stuff around on other terminals (actually, for dumb
termiansl this would require the VD system to maintain a screen image, which
may or may not be a good idea (but Concept-LNZ's DO have such an operation))).
Perhaps we need to decide on operations before we determine if there needs to
be the distinction that Scott suggests there ought to be. I think a virtual
display should try its best to perform an operation, but quietly ignore the
request if it can't hack it. It could bum someone out if a nifty piece of
software didn't run on her computer just because she had a dumb terminal. If
instead, the display just didn't look as nifty on an ADM-3A as it does on a
Lisp Machine, then the user will probably be forgiving.
From: boetje at DEC-HUDSON
I think the discussion of structures vs object implementation is getting a
little off track.
I was attempting to show that the niceness of an object-oriented approach could
still be had within the Common Lisp language, and with structures. Perhaps I
should have said "Object oriented programming is a style, and one can write
stylized Common Lisp," and left out all the code in my last message.
My intention is that we document and standardize creation, accessing and
setting functions that look like
...
as opposed to instancing of objects and sending messages to the instances.
Sure. Note that the Display-Char function (intended to be the user-level call)
in my example hid the object oriented implementation. Streams are the done the
same way, for us.
I think that under no circumstances should we document a particular
DEFSTRUCT implementation and require all Common LISPs to have this. I think
that the only reason to do this (and it's part of the example Skef gives)
is to allow users to support output devices not explicitly supported by the
vendor.
So we're just working on a spec here, and not a portable implementation. Ok.
I think a portable implementation or two will come out of this, though. The
people doing those implementations probably want to think hard about
extensibility for the sake of porting to new environments in addition to
supporting new devices.
We can probably have some high level inquiry functions that let the user
know the general category of device (bitmapped, color, vector, cell, etc).
Each category would have a certain level of functionality that's required
(by the standard) for that device and a certain set that's optional and up
to the implementation (eg, narrow virtual displays on a VT100).
I have a feeling that trying to do things in explicit levels is going to let
capabilities of some terminals fall through the cracks. I claim that the
problem Scott brought up in the first paragraph quoted above can work in
reverse -- some character-oriented CRT's can do operations like
raster-oritented displays, and others can do different ones. Maybe this isn't
a problem, but we can't tell for sure until we get into specifics. Anyone up
for that?
--Skef
∂21-Nov-84 0724 FAHLMAN@CMU-CS-C.ARPA Virtual Displays
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 07:23:14 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 21 Nov 84 10:22:01-EST
Date: Wed, 21 Nov 1984 10:21 EST
Message-ID: <FAHLMAN.12065345435.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
Cc: CL-Windows@SU-AI.ARPA
Subject: Virtual Displays
In-reply-to: Msg of 20 Nov 1984 11:48-EST from Skef Wholey <Wholey>
I'm not sure if my view of the dividing line between CL-WINDOWS and
CL-GRAPHICS matches other people's. I had been assuming that such
things as the primitive calls to display characters in a window at
arbitrary places, draw lines, color in rectangles, and so on were the
provine of the window package, and that any graphics standard is more
concerned with higher-level software to help decide which lines to draw
where. (If graphic means anything that is written into a virtual
display at all, then we have to consider graphics and windows together
because at that level they are inseparable.)
If my view of the division is correct, then there are several examples
of things that a raster-scan display could do that would have no
immediate counterpart on a dumb terminal: draw lines from one point to
another, display an arbitrary character from an arbitrary font at a
specific location specified in pixels, rotate a chunk of the screen,
return a mouse-click (or some other kind of pointer-selection) in window
coordinates, etc.
I think that it is a terrible mistake to rule out any of these
operations for raster displays just because there is no good equivalent
on an 24x80 character terminal. I also think that it is not in general
possible to have the built-in window-based software fake all of these
things in "the best way possible" on the dumb terminal. There's just no
good way to fake a drawing program on an Adm-3A, and I'd rather have the
software fail cleanly than waste a lot of time trying. Maybe a clever
application programmer can figure out some way to fake his particular
drawing program on a dumb terminal, using the impoverished set of
operations available there, but that should be his problem and not the
Lisp implementor's problem.
So, revised proposal:
We divide features that a diplay might have into broad classes that tend
to go together: Multiple windows, Advanced cursor commands, Pixel
operations, Pointing device, Color, Multiple Fonts, etc. Some of these
have parameters, such as the X and Y dimensions of the screen in
characters or pixels. Each display/implemenation is required to
indicate which of these things it has and the values of its parameters,
and therefore what operations it supports. Software will be written to
assume some set of these feature groups, and the necessary support will
be advertised with the documentation for the software. If I want my
package to run on ANYTHING, I assume a very minimal set of support; if I
don't want to live with those restrictions, then I assume more. The
best software providers will conditionalize their code so that if some
feature like color is present, it is used, but if it is not present they
compensate for this in some other way; others may choose not to bother
trying to cope with dumb displays.
-- Scott
∂21-Nov-84 0914 DDYER@USC-ISIB.ARPA Implementation strategy
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 09:14:26 PST
Date: 21 Nov 1984 09:13:20 PST
Subject: Implementation strategy
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
Now that I've lighted the fire, I'll add my contribution to the fuel.
We have to define virtual display operations in a way that is acceptable
to the major implementations, or else the definition will simply be
rejected as brain damaged and ignored. In particular, it should be
obvious that Symbolics isn't going to re-implement their window system
using structures. It's just as obvious, as was pointed out, none
of the other CL implementations will have a robust and portable object
oriented system for an indeterminate time. Therefore, we must define
something compatible with either strategy, and preferably, one that
will permit the underlying implementation to change, as object
systems become available.
What this amounts to is defining a limited object oriented system,
which maximizes information hiding but makes no commitment about
implementation. The last time I implemented such a system, my
basic primitives looked like this.
(SCREENOP <<window>> <<operation>> &rest args)
Honest Injun, I came up with it before I ever wrote my first DEFFLAVOR!
This was implemented by a hairy macro, which expanded to structure
manipulations appropriate to the operation. To hack efficiency,
one "operation" was :GET-HANDLER-FOR and another was :INVOKE-HANDLER-FOR.
We might also want an environment macro like
(WITH-SCREEN-ENVIRONMENT (VAR WINDOW) --)
Where WINDOW would be decoded (whatever that means) so that references
to VAR would know the exact type of the operand.
The advantages of this approach are that it is easy to transform
into efficient code for most any implementation, it avoids embedding
implementation details in user code, it makes screen manipulations
easily identifiable, and it avoids polluting the global environment
with arbitrarily many names of operations. I strongly favor this
kind of surface structure for invoking display operations.
The problem of creating an abstract syntax for defining window types
is stickier.
-------
∂21-Nov-84 1048 KACZMAREK@USC-ISIF.ARPA Re: Virtual Displays
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 10:48:12 PST
Date: 21 Nov 1984 10:45:02 PST
Subject: Re: Virtual Displays
From: Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
cc: cl-windows@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12065345435.BABYL@CMU-CS-C.ARPA>
Typical graphic standards provide a great deal of functionality regarding
the display of lines, circles, points, raster images, and characters. They
also provide for clipping regions, rotation of images, panning, zooming, and
scaling. I think that a window package should be built on top of graphic
support. We should assume the existence of font support (including producing
bitmaps for text strings), clipping, line drawing, shading, texturing,
coloration, etc.. We should also presume high level primitives for
pointing devices ala GKS and the Siggraph Core standard.
I suggested this in an earlier message but no one seemed to pick up on it
other than to say they wanted to do all the low-level stuff. I would like
to get a measure on how many people think that windows are at a higher
level than graphics. I see windows as graphic structures with fairly
restrictive constraints--they are a major component of the user interface
with highly stylized behavior. They have to be flexible enough to allow an
application programmer to mold the user interface to his liking, yet
restrictive enough so that the user is not overwhelmed by inconsistencies.
I think we ought to check with the graphics group also to get their
feelings to make sure we are not duplicating efforts.
Tom
-------
∂21-Nov-84 1250 greek@DEC-HUDSON Terminal features and graphic functions
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 12:49:51 PST
Date: Wed, 21 Nov 84 15:50:10 EST
From: greek@DEC-HUDSON
Subject: Terminal features and graphic functions
To: cl-windows@su-ai
I basically agree with what Scott says about categories of features.
Perhaps we might even end up with some standard symbols in *FEATURES*
for testing by programs. However, I'm dubious as to the patience
of developers as they try to write code that uses as many features
as possible but avoids ones not on the current terminal. This kind
of code is difficult to write, and people just tend to write
for the lowest common denominator, or say "screw" to all but the
smartest terminals.
I think we can define virtual displays that will work pretty well
on many kinds of terminals. If we said that all, or almost all,
operations had to work on all terminals, and forced implementors
to think of ways to do these on dumb terminals (or noop them), we
would be doing the world a favor. As for complex graphics, that
have no counterpart on dumb terminals, perhaps we shouldn't be
treading on that ground. Graphics is not a solved problem.
Dave - I don't understand why your statements about window
compatibility with existing implementations leads you to believe
that the operations must be object-oriented. What's wrong with
50 functions? If Symbolics implements these as macros that turn
into flavorful things, no problem. Streams are object-oriented,
structures aren't, hash tables aren't, arrays aren't. Why start
now, when we haven't agreed on object-oriented features for CL?
(Read that as "streams aren't object...").
- Paul
∂21-Nov-84 1434 @MIT-MC:MONTALVO@MIT-OZ Re: Virtual Displays
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 14:34:23 PST
Date: Wed 21 Nov 84 17:31:34-EST
From: Fanya S. Montalvo <MONTALVO%MIT-OZ@MIT-MC.ARPA>
Subject: Re: Virtual Displays
To: KACZMAREK@USC-ISIF.ARPA
cc: Fahlman@CMU-CS-C.ARPA, cl-windows@SU-AI.ARPA, MONTALVO%MIT-OZ@MIT-MC.ARPA
In-Reply-To: Message from "Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>" of Wed 21 Nov 84 10:45:02-EST
I think a lot of the issues being raised by cl-windows are relevant to
cl-graphics, and that the relationship between windows and graphics
should be discussed by cl-graphics, also.
I see windows as a subset of graphics. Support for windows is a
specific kind of functionality that a graphics package may or may not
have. As a subset, it's neither higher nor lower than graphics. It
may rely on low-level primitives, but in turn, some even higher level
functionality may rely on it.
And by the way, I'm on cl-graphics also, and may have missed the
discussion of how the division was being made. If it was already
discussed just forward the relevant messages (not too many please).
Fanya
-------
∂26-Nov-84 0717 boetje@DEC-HUDSON graphics, virtual displays, and terminals
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 26 Nov 84 07:16:27 PST
Date: Mon, 26 Nov 84 10:13:21 EST
From: boetje@DEC-HUDSON
Subject: graphics, virtual displays, and terminals
To: cl-windows@su-ai.arpa
On categories of features, here's one suggestion for a basic division...
Take some dumb terminals of the VT100 class. These have the ability to
position a cursor to an arbitrary cell location and write ASCII characters
This is sufficient capability support virtual displays which can have a border
and a label. The set of operations has to be restricted to manipulating text
on a cell-oriented terminal (ie, no proportional fonts). There is a suprising
amount that can be implemented on such a terminal: show arbitrary sized
displays, insert and delete characters (easier on a cell terminal), scroll
lines of text in a display, occlude displays, pick and point via cursor
manipulation and even draw horizontal and vertical lines. For a dumb terminal,
that ain't bad.
The other category then becomes the bitmapped tubes. Let's just assume they
can do whatever we think up (although character insertion and deletion is
harder on these terminals). It's up to us to establish a reasonable set of
operations that should be supported.
So I'd choose two categories: the kitchen sink and the text only. The text
only terminal is required to be cell-oriented and have the capability to
position the terminal cursor at an arbitrary cell position. It can support all
the capabilities needed for a screen editor. The kitchen sink terminal is
bitmapped and can support an arbitrary level of complexity in its display
operations.
On the division of virtual displays and graphics...
The more I've thought about it, they really are fairly separate topics which
have one area of overlap. Each topic has a number of basic operations and
concepts which don't relate at all to the other. For example, a discussion of
virtual displays gets into issues of display management which includes ideas
such as stacking, occlusion and selection. Graphics deals a lot with
coordinate transformation, line drawing, graphical objects and area fill.
The one area of overlap can be neatly defined if we define the picture area of
a virtual display to be that portion of a display inside of things like labels,
borders and margins. The picture area is where most everything of interest
happens in a virtual display. The picture area is also allowed to be a
graphics viewport onto some data space (such as NDC for you GKS fans). If we
accept this definition, then the tasks of the display committee and the
graphics committee become a bit easier. We need to refine things such as the
coordinate system of the virtual display. Once this is done, the graphics
committee can concern itself with coordinate transformations, composition,
basic operations and picking. The display committee can be concerned with
management of virtual displays, use of a virtual display in place of a CL
stream, and the definition of what surrounds a virtual display (labels,
borders, margins, etc).
Jerry
∂08-Dec-84 1642 DDYER@USC-ISIB.ARPA Easy Questions
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 8 Dec 84 16:42:42 PST
Date: 8 Dec 1984 16:41:41 PST
Subject: Easy Questions
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
I'd like to gauge the "real world" concerns of the members of this
list regarding portable windows. Feel free to editorialize. The
questions are:
What existing, under development, or planned programs
would use common lisp's window system if it had one?
What existing, under development, or planned programs
would NOT use common lisp's window system, even if
it had one? Why?
-------
∂08-Dec-84 1927 FAHLMAN@CMU-CS-C.ARPA Easy Questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Dec 84 19:27:18 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 8 Dec 84 22:27:55-EST
Date: Sat, 8 Dec 1984 22:27 EST
Message-ID: <FAHLMAN.12069934029.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dave Dyer <DDYER@USC-ISIB.ARPA>
Cc: cl-windows@SU-AI.ARPA
Subject: Easy Questions
In-reply-to: Msg of 8 Dec 1984 19:41-EST from Dave Dyer <DDYER at USC-ISIB.ARPA>
This question is not so easy. The answer depends totally on what the
standard Common Lisp window system ends up looking like. In the Spice
Lisp system (on the Perq, at present) we now have a simple set of Lisp
function calls that gives us efficient access to the window and graphics
operations available in the system: window creation and deletion, what
appears in the title line and progress bar, what appears in the icon
associated with the window, line drawing, character moves, raster ops,
reading from the screen bitmap, and so on. Actually, all of these
services are provided outside of the Lisp process, and the calls turn
into messages to the system kernel or to the screen-manager process, but
the user doesn't need to know that.
If the window/graphics standard turns out to be a set of function calls
that gives us access to all of the same kinds of operations, then we
would probably use it for most of our graphics-oriented applications and
possibly even for the Hemlock editor. This would become the standard
set of screen-oriented function calls in our Lisp system.
If the standard provides access only to a small subset of the Spice
display facilities, or enforces a substantially different view of the
display abstractions than our system supports, or if it is grossly
inefficient for some reason, then we would probably use the native Spice
calls for all of our local programming, but would occasionally translate
certain vanilla applications or utilities into the Common Lisp
graphics/window standard for export.
If, in the interest of extensibility or whatever, the standard window
system ends up being object-oriented and ultra-hairy like the current
Zetalisp window system, I don't think it will be used at all at CMU,
except by the one or two people who have been writing graphics code on
our Lisp machines and have somehow manged to figure this stuff out.
-- Scott
∂11-Dec-84 1207 DDYER@USC-ISIB.ARPA Re: Easy questions
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 11 Dec 84 12:07:22 PST
Date: 11 Dec 1984 12:02:13 PST
Subject: Re: Easy questions
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
Replies from:
8-Dec Kent M Pitman easy questions? (1327)
8-Dec John W. Peterson Re: Easy Questions (3632)
------
Date: 8 December 1984 19:54-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: easy questions?
Actually, the second question is quite hard. It's easy to say
"Oh, yeah, if you provided me a window system, I'd use it for ..."
without knowing what it offered because it's a "friendly" thing to
say and people will be willing to suppose your window system will
"meet their needs". Saying I wouldn't use a window system even
if you gave it to me is to say you don't believe it would meet your
needs no matter what, which either says you strongly believe that
there are two different viable theories of window systems and that
you want one but believe CL will provide the other, or that you
believe there's only one such system and CL doesn't stand a chance
in hell of going the right direction.
Anyway, it occurs to me that you might ammend the second question, or
add a third, to find out what features that if a window system lacked
would make it useless, or what features that if a window system had
would make it useless. eg, you might have said:
"What kind of window system would not suit some existing, under
development, or planned program?"
-kmp
Date: Sat 8 Dec 84 18:25:06-MST
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Re: Easy Questions
What existing, under development, or planned programs
would use common lisp's window system if it had one?
I'm currently working on a CAGD (Computer Aided Geometric Design) system under
lisp. It is extensivly window based, and designed to be portable to some
degree (versions currently run on devices such as Apollo domains and Evans &
Sutherland PS300 Vector engins). The system is "different" from most CAD
environments in that a program (a "procedural model") is written to describe
the part you are constructing. These programs "emit" B-Spline surfaces, which
are then used to generate shaded images, N/C toolpaths, etc. We use
interactive (3-Dimensional) graphics to view the model as it is constructed.
This is coupled with a special version of SETF that displays the graphics
representation of an entity (point, line, arc, curve, surface, etc) in a
graphics window when it's value is assigned. Multiple graphics windows can
be used to view differnt (or different views of the same) geometric
constructions. At any time you can grab a knob and rotate the geometry in
a 3D window to get a better view (this happens in real time on the E&S tubes,
step-by-step on less powerful displays).
Since the model is built from a lisp program, a text editor (usually a full-
featured EMACS) window is used to write the program in. You evaluate your
program step-by-step in the emacs window; and see the geometric results in
the graphics window as you go along.
A current (and very tricky!) research issue is to be able to interactivly
modify the graphics representation of the model (in the graphics window) and
have these changes reflected in your program. Thus, the textual representation
of the model in your EMACS window would get automaticly updated, much like
the graphics is updated now when you change the text. [A master's student
here has done some preliminary work with this].
Currently this is all done with, well, a lot of masking tape. We have a
PSL (Portable Standard Lisp) process running under the control of Gosling's
emacs. The PSL process in turn drives the several graphics windows, updating
them whenever a SETF occurs on a geometric object. In my ideal universe,
this would be running as a single Lisp program on a powerful Lisp Machine.
But these weren't readily available to us when we started (80-81), and
many of our contractors would still balk at an $80K/User workstation.
Hmmm, that's probably a longer discription than you bargianed for, but I guess
it's a useful example of a -complex- application for a Lisp-based window
system. After all, I want these windows to do everything from powerful
text editing to real-time 3D graphics...
PS
I would find a summary of the applications you here about interesting. And
as to your other question:
What existing, under development, or planned programs
would NOT use common lisp's window system, even if
it had one? Why?
About the only code I can think of that falls into this catagory are
ones that aren't interactive (i.e, rendering programs that take a long time
to run). But even then, I STILL want those windows for debugging and editing
it!
-------
-------
∂12-Dec-84 2201 RAM@CMU-CS-C.ARPA Easy Questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Dec 84 22:01:46 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 13 Dec 84 01:02:24-EST
Date: Thu, 13 Dec 1984 01:02 EST
Message-ID: <RAM.12071010731.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Dave Dyer <DDYER@USC-ISIB.ARPA>
Cc: cl-windows@SU-AI.ARPA
Subject: Easy Questions
I have a suspicion that the Hemlock text editor will not use any
window standard which may be agreed upon. Hemlock is currently in use
in the CMU community, and a much mutilated early version forms the
basis of the DEC VAX Lisp editor. It is about 20k lines of largely
portable Common Lisp code. The current Hemlock screen manager is
inadequate, and one of my current projects is to design a new one.
The main functions of the screen manager will be the following:
1] Allocate windows in a manner culturally compatible with EMACS.
2] Provide primitives for drawing strings and copying and clearing
screen areas.
3] Provide some sort of abstract interface to multiple fonts of
varying heights and widths. I have something in mind along the
lines of Scribe font-families.
4] Deal with demultiplexing keyboard and mouse input.
5] Provide some sort of abstract interface to the software interrupts
generated by our window system when windows are exposed or
resized.
6] Have some sort of support for highlighting.
Some reasons I don't think that a portable window manager is likely to be
usable:
A] Some of things that need low-level support in the window system
(4, 5) probably cannot be resolved to everyone's satisfaction.
B] Efficiency is important, thus it may be desirable to add special
primitives to make the drawing primities provided more closely
correspond to those actually supported.
Other comments:
I am not very impressed by environment query functions, or rather
the programming style they seem to encourage. Redisplay, which is the
level above the screen manger, needs to have a very good idea of what
the device can and cannot do. What I intend to do is have several
different versions of redisplay which are selected on the basis of the
general class of device driven, e.g. bit-mapped screen, windowing
terminal, smart terminal, dumb terminal. If it is necessary to have
significant procedural knowledge about the device at a level above the
window system to attain good performance across a wide range of
devices, it is futile for the window system to attempt to hide the
fundamental characteristics of the device.
If graphics includes such things as scaling, symbols, rotation and
arbitrary coordinate transforms, then I think that it is wrong to
think of "Windows" as being a layer above "Graphics". It is true that
any window system will be based on some set of graphical primitives
for doing things such as rasterop and drawing lines, but these things
will operate in device units, and thus will not be the primitives of
the graphics system. I suspect that it is much more probable that the
graphics system be built on the window system, since graphics will
probably be done on the windows or "virtual displays" provided by the
window system, while the window system will have no use for any of the
hair provided by the graphics package.
Rob
∂09-Jan-85 0110 DDYER@USC-ISIB.ARPA This space intentionally left blank
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 9 Jan 85 01:10:32 PST
Date: 9 Jan 1985 01:07:31 PST
Subject: This space intentionally left blank
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
I've been impressed by both the high quality and the low volume
of discussion on this mailing list. I think this is indicative
of an unfortunate state of affairs. We collectively appreciate
the nuaces of and appreciate the magnitude of "the window problem",
hence the high quality. We collectively agree on most issues of
substance, hence the low volume.
This would be fine, except there is no CL window system, and
at this rate, there never will be! Why this paralysis? I suspect
we also share the resigned realization that a combination of
vested interests and inertia will defeat any effort to establish
a standard.
-------
∂09-Jan-85 1001 KACZMAREK@USC-ISIF.ARPA Dire Dyer Prediction
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 9 Jan 85 10:01:43 PST
Date: 9 Jan 1985 08:02:54 PST
Subject: Dire Dyer Prediction
From: Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>
To: cl-windows@SU-AI.ARPA
In-Reply-To: (Message from "Dave Dyer <DDYER@USC-ISIB.ARPA>" of 9 Jan 1985 01:07:31 PST)
I think that the dire Dyer prediction is premature.
I take the volume of messages for this group as a positive sign. It has
been considerably higher for this group than for the two other groups I
know about. The volume of messages has reduced lately indicating, as Dave
points out, agreement on the issues. (Should the volume be seasonally
adjusted? We have all probably had more vacation days/holidays recently
than normal.) I think any drop in volume indicates that we are at a
critical point--we are ready to start the process of design. I would
suggest that we need someone, preferably who already has a design for a
window system, to step forward and propose it as the standard. (If more
than one volunteer steps forward we ought to consider multiple proposals.)
Published proposals followed by a several day workshop to discuss them
seems appropriate to me.
The proposals are sure to cause controversy and vested interests are
certainly going to play a part in the negotiations that follow. Some
groups will decide not to follow the standard and others will. That is
nothing new. I don't think we ought to admit defeat just yet.
Tom
-------
∂09-Jan-85 1117 DDYER@USC-ISIB.ARPA Re: This space intentionally left blank
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 9 Jan 85 11:17:08 PST
Return-Path: <JW-PETERSON@UTAH-20.ARPA>
Received: FROM UTAH-20.ARPA BY USC-ISIB.ARPA WITH TCP ; 9 Jan 85 01:33:45 PST
Date: Wed 9 Jan 85 02:35:55-MST
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Re: This space intentionally left blank
To: DDYER@USC-ISIB.ARPA
cc: JW-Peterson@UTAH-20.ARPA
In-Reply-To: Message from "Dave Dyer <DDYER@USC-ISIB.ARPA>" of Wed 9 Jan 85 01:07:31-MST
ReSent-Date: 9 Jan 1985 11:16:59 PST
ReSent-From: Dave Dyer <DDYER@USC-ISIB.ARPA>
ReSent-To: cl-windows@SU-AI.ARPA, cl-graphics@SU-AI.ARPA
A related question. I thought (or at least was under the impression) that
I was tuned into the CL-GRAPHICS list as well. I have not heard a *peep* out
of that list, do you know if it's active?
This is somewhat relavent to CL-Windows, since I am from the school of thought
that the window system should know about (and perhaps be based on) the
graphics support. To some extent, I've been "waiting" to see what that list
says (This may hold true for others as well, e.g., the "units of measurement"
discussion a while back).
Cheers.
-------
∂09-Jan-85 1322 boetje@DEC-HUDSON here's something to make up for the long silence... Jerry
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 9 Jan 85 12:59:45 PST
Date: Wed, 09 Jan 85 15:10:33 EST
From: boetje@DEC-HUDSON
Subject: here's something to make up for the long silence... Jerry
To: cl-windows@su-ai.arpa, cl-graphics@su-ai.arpa
9 January 1985
COMMON LISP
Graphics Models
!
Page ii
CONTENTS
1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 1
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . 1
1.2 Terms . . . . . . . . . . . . . . . . . . . . . . 1
2 GENERAL CONCEPTS . . . . . . . . . . . . . . . . . . 2
3 COORDINATE SYSTEMS . . . . . . . . . . . . . . . . . 4
3.1 Application, World, User Coordinates . . . . . . . 5
3.2 Master, Object Coordinates . . . . . . . . . . . . 5
3.3 Physical Device Coordinates . . . . . . . . . . . 5
3.4 Logical Device Coordinates . . . . . . . . . . . . 6
3.5 Virtual Display Coordinates . . . . . . . . . . . 6
3.6 Normalized Device Coordinates (NDC) . . . . . . . 7
4 TRANSFORMATION . . . . . . . . . . . . . . . . . . . 8
4.1 Rotation . . . . . . . . . . . . . . . . . . . . . 8
4.2 Scaling . . . . . . . . . . . . . . . . . . . . . 8
4.3 Translation . . . . . . . . . . . . . . . . . . . 8
5 TRANSFORMATION OPERATIONS . . . . . . . . . . . . . 9
5.1 Matrix Representation . . . . . . . . . . . . . . 9
5.2 Window-Viewport Transformation . . . . . . . . . . 9
5.3 Active Transformation . . . . . . . . . . . . . 10
6 CLIPPING RECTANGLE . . . . . . . . . . . . . . . . 10
7 COMPOSITION . . . . . . . . . . . . . . . . . . . 11
7.1 Composition Space . . . . . . . . . . . . . . . 11
7.2 Segments . . . . . . . . . . . . . . . . . . . . 12
7.3 Virtual Display Composition . . . . . . . . . . 12
7.4 COMMON LISP Composition Levels . . . . . . . . . 13
8 ATTRIBUTES . . . . . . . . . . . . . . . . . . . . 13
8.1 Attribute Descriptions . . . . . . . . . . . . . 13
8.2 Attribute Inheritance . . . . . . . . . . . . . 16
9 VIRTUAL DISPLAYS . . . . . . . . . . . . . . . . . 17
9.1 Composition Space . . . . . . . . . . . . . . . 18
9.2 Picture Area . . . . . . . . . . . . . . . . . . 18
9.3 Banner Area . . . . . . . . . . . . . . . . . . 18
9.4 Border . . . . . . . . . . . . . . . . . . . . . 19
9.5 Margin . . . . . . . . . . . . . . . . . . . . . 19
9.6 Virtual Display Window . . . . . . . . . . . . . 19
9.7 Device Viewport . . . . . . . . . . . . . . . . 19
9.8 LISP Terminal Streams To Virtual Devices . . . . 19
9.9 Input Cursor . . . . . . . . . . . . . . . . . . 20
10 POINTING AND PICKING . . . . . . . . . . . . . . . 20
10.1 Pointing . . . . . . . . . . . . . . . . . . . 21
10.2 Picking . . . . . . . . . . . . . . . . . . . . 21
11 DISPLAY MANAGEMENT . . . . . . . . . . . . . . . . 21
11.1 Visibility And Stacking . . . . . . . . . . . . 22
11.2 Sensitive Regions . . . . . . . . . . . . . . . 23
11.3 Menus . . . . . . . . . . . . . . . . . . . . . 23
11.4 Pointer And Selection . . . . . . . . . . . . . 23
12 BITMAPS . . . . . . . . . . . . . . . . . . . . . 24
!
COMMON LISP Graphics Models Page 1
INTRODUCTION
1 INTRODUCTION
1.1 Purpose
This somewhat ambitious document is an attempt to establish a common
framework for discussions of graphics, windows, virtual displays, and
all the supporting concepts that go along with them. It specifically
doesn't define LISP functions yet. My claim is that without agreement
at the level of concepts and terminology, we can't possbly get started
on defining LISP functions.
The material presented here covers concepts and terms which properly
belong to both the graphics and windows committees. The reason for
this is to present a unified view toward video displays before we
define functions. I believe that when we start defining functions,
we'll find a fairly neat partition of functions between graphics and
virtual display creation and management. But we're less likely to
have functional incompatibilities if we can agree on some high level
ideas.
A section missing from this document is a discussion of levels of
capabilities that can be supported by various hardware and software
implementations. I'd welcome ideas on this. As a first cut, I'll
propose three levels:
1. That which you can do on a cell-oriented character terminal
such as a VT100 (text editor capabilities, multiple displays
and simple menus).
2. Add basic graphics operations but without composition. Level
2 might include restricted composition of virtual displays
(no additional scaling or rotation) much like the frame/pane
systems around.
3. Full multi-level composition capability and allowance for
user-written N-dimensional processing.
With some luck, this should start a new flood of discussion. Happy
reading.
1.2 Terms
Terms will be defined in this document by establishing the concepts
they represent. This will not only provide context and explanation
but show the functional interrelationships among the various terms.
Where possible, "established" terms will be used. A difficulty with
the current industry environment is that the same word (e.g.
"window") is often used to represent very different concepts. Such
industry discrepancies will be noted.
At least the following terms will be defined:
!
COMMON LISP Graphics Models Page 2
INTRODUCTION
Attribute
Clipping rectangle
Composition
Display management
Picking
Pointing
Segment
Transformation
Viewport
Virtual display
Window
The presentation of conceptual models is designed to explain and
illustrate both the generalization of certain techniques, such as the
window-viewport transformation, and the methods by which COMMON LISP
integrates the various objects and operations that support the
workstation.
2 GENERAL CONCEPTS
This paper deals with the concepts used in displaying data on a video
terminal. Such a display might be as simple as placing consecutive
lines of text on a screen. It might also involve drawing lines,
shading figures, and overlapping independent displays. This process
can be made arbitrarily complex. Certain conventions and techniques
have evolved for defining and managing this process. Unfortunately,
different conventions and terminology have evolved in the different
worlds of display management and graphics. Much of this paper
describes a system of terminology and concepts which attempts to unify
the different approaches taken by display management and graphics.
The remainder of this section will describe the display process in
general (and not always immediately defined) terms.
The basic displayable object is a "virtual display." This is a
rectangular area which can be associated with (made visible on) the
screen of a video display device. A virtual display can have a
"banner" (identifying information), a "border" (a pattern that
outlines the virtual display), a "picture area" (the inside of the
display where information can be shown), and up to four "margins"
(space between the border and the picture area).
The simplest kind of information display involves creating a virtual
display and writing text into its picture area by using the normal
COMMON LISP stream output operations.
The next level of complexity involves doing graphical operations to
the picture area of a virtual display. Graphical operations are those
which (loosely speaking) produce non-text images in the virtual
display. They include operations such as drawing lines and polygons,
filling areas with some pattern, and putting graphical symbols at
points.
!
COMMON LISP Graphics Models Page 3
GENERAL CONCEPTS
Graphical operations usually require one or more pairs of coordinates
to give the location(s) of the output. A virtual display's picture
area has a coordinate system with its origin (location 0,0) at the
lower left corner. The location of points in the picture area can be
given by specifying offsets into the picture area along the horizontal
(X) and vertical (Y) axes. These offsets, as well as the bounds of
the picture area, are expressed in centimeters.
All supported graphics operations can be done directly in a virtual
display, as long as the coordinates are restricted to those that fall
roughly within the bounds of the picture area. However, not all data
in the world falls numerically within the bounds of a picture area.
For example, a physicist might want to graph pion production rate vs.
impact energy in furlongs per fortnight. In order to present a visual
depiction, the data (in both axes) must be scaled and translated in
order to fit into the bounded coordinate system of a picture area. It
may also need to be rotated about some axis. This process is known as
"coordinate transformation." What is required is a method that defines
the appropriate transformation and thus allows the user to express his
data in the most convenient units. The commonly selected method is
called the "window-viewport transformation."
A "window" is a rectangular area usually specified in the coordinate
system of the user data. This user coordinate system is called the
"application data space." The specification of a window is really a
statement that says "all data of interest to me falls in this range."
A "viewport" is a rectangular area defined in the coordinate system in
which the graphical representation of the data will be kept or
displayed. Such a coordinate system might be that of a virtual
display, with the viewport defined to be all or part of the virtual
display's picture area. The specification of a viewport is a
statement that "this is where I want to see the pictorial view of my
data."
At the simplest level, a window-viewport transformation might involve
the definition of a window in a user's application data space and an
associated viewport which is the picture area of a virtual display.
Now the user is free to draw lines and do other graphical operations
in the coordinate system of his data. The results will appear in the
picture area of the virtual display.
Now that the transformation operation is defined, a further
complication can be introduced: the notion of "composition."
Composition means the building up of a graphical object in a separate
coordinate system (the "composition space"). In the previous case,
the picture area of a virtual display was used as a composition space.
There is no reason that the notion of composition cannot be combined
with transformation to enable production of arbitrarily complex
graphical systems. For example, the Graphics Kernel System (GKS)
defines two levels of composition and transformation. GKS comes with
a predefined composition space called Normalized Device Coordinates
(NDC) which has bounds at (0.0,0.0) and (1.0,1.0). The user first
!
COMMON LISP Graphics Models Page 4
GENERAL CONCEPTS
specifies a transformation from application data space into NDC. Then
additional transformations are created which map portions of NDC space
onto the physical device screen (which is treated as another
composition space).
This complexity can be increased since this process can go to any
level if the user is allowed to create independent composition spaces.
The graphics world has created the concept of "segments" to represent
independent composition spaces. These composition spaces are
typically mapped onto multiple viewports so that a single graphical
object may be viewed simultaneously in many places. For example, the
symbol for a NAND gate is drawn in an independent composition space
which is then mapped into multiple places in a circuit diagram.
"Display management" refers to the means supplied to position virtual
displays on the screen and to determine which shall be visible.
Virtual displays are made visible on the screen by associating them
with the screen. Since virtual displays are opaque, they can hide, or
"occlude," other virtual displays. The display management system must
therefore determine which virtual display will be occluded when two
overlap on the screen. The system does this by consulting the
"stacking order" to see when each display was associated with the
device. The position of a virtual display in the stacking order can
be altered, or the virtual display can be removed from the stacking
order altogether.
The display management system must also provide means to move virtual
displays on the screen and to change their shape and size.
A pointing system allows the user to move a cursor around the screen
in order to indicate positions where operations should take place or
to choose some object (such as a menu selection) from a display. The
positioning operation is called "pointing" and the process of using
the pointing system to choose an object is called "picking." Certain
areas of the display can be made sensitive to the pointing system's
cursor so that an action can be triggered when the cursor enters or
leaves the sensitive area.
With this introduction, the remainder of the paper goes on to more
rigorously define these and other concepts of a possible COMMON LISP
graphics and display model.
3 COORDINATE SYSTEMS
Much of the confusion around displays, graphics, bitmaps, etc. has to
do with the use of different coordinate systems and the
transformations between them. Several coordinate systems will be used
in later discussions. Some of the important ones are defined here.
!
COMMON LISP Graphics Models Page 5
COORDINATE SYSTEMS
3.1 Application, World, User Coordinates
These terms all loosely refer to the same idea of an unbounded,
N-dimensional space of floating-point numbers, where N is typically 2
or 3. As used in graphics systems, these terms really refer to the
coordinate system in which some particular set of graphical operations
(draw line, draw point, etc.) is performed. Another way of stating
this is that these are the most convenient coordinates in which a user
can graphically describe his data.
For example, for a graph of volume of sales by year, it's most
convenient for the user to give the data to the graphics system as
number pairs representing millions per year. The graphics system is
then responsible for eventually transforming this data to the
coordinates of the display device and displaying it.
There is no composition implied by the specification of several
graphical objects in overlapping application coordinates. For
example, several objects may be drawn in a range of coordinates from
(1.0,1000.0) to (5.0,1000.5) and yet they will not appear together in
the display if they are directed to different composition spaces.
All output operations are specified in application data space and are
transformed into a composition space. This implies that there can
only be a single "active transformation" in effect at any given time.
(See Transformation Operations for more information on the active
transformation.)
This paper will use the term "application data space" when referring
to the coordinate system in which the user performs the basic
graphical operations that build an object.
3.2 Master, Object Coordinates
These terms refer to the coordinate system defined by some composition
space used to describe a particular object. The coordinates are
expressed as floating-point numbers. This new object may be a part of
a larger drawing in one or more different composition spaces.
This paper will use the term "master coordinates" for coordinate
systems used in this way.
3.3 Physical Device Coordinates
Physical device coordinates consist of a bounded set of
two-dimensional integer coordinates that specify the addressable
positions of an output device's display area. The device coordinates
themselves do not specify the absolute size of an addressable unit.
The unit may be a pixel on a bitmap terminal, or a character cell on a
character terminal. Each implementation must supply functions which
!
COMMON LISP Graphics Models Page 6
COORDINATE SYSTEMS
give the physical size of the addressable units of the device, for
example, the height and width of a pixel. This allows users who wish
to work in the physical units of the device to scale their coordinates
appropriately.
The numeric range of each axis is defined by the physical device
itself, as are the location of the origin and the direction of the
axes. For example, a character terminal may have an origin at (1,1)
in the upper left corner of the screen with the X bound of 80 or 132
and the Y bound of 24. A particular bitmap terminal may have an
origin at (0,0) in the lower left corner with X and Y ranges of 767
and 468.
3.4 Logical Device Coordinates
Logical device coordinates are two-dimensional coordinates with
floating-point values. Logical device coordinates specify, in
centimeters, locations on a "logical device" which is independent of
the particular physical display device. Furthermore, logical
coordinates always have a (0,0) origin at the lower left corner of the
display screen. The logical display screen thus corresponds to the
upper right quadrant of a conventional X-Y coordinate system.
Since logical device coordinates always specify measurements in
centimeters, an object or display that is described using logical
device coordinates will have the same size and shape on any output
device. Users who wish to work in physical device coordinates can use
the functions that give the size of a physical device unit to control
the size and shape of their images. (See Physical Device Coordinates,
above.)
This paper will always use the term "device coordinates" in the sense
of "logical device coordinates" unless otherwise stated.
3.5 Virtual Display Coordinates
Virtual display coordinates are two-dimensional floating-point
coordinates that specify locations within a virtual display. The
units of the virtual display coordinates are the same as the units of
the logical device coordinates, that is, centimeters.
Since virtual display coordinates and logical device coordinates share
the same units and since both have origins in the lower left corner,
the position of a point in a virtual display on the logical display is
a pure translation of that point from the origin of the logical
display coordinate system. In other words, only translation is
required when placing or shifting a virtual display on the logical
device; no scaling or rotation is needed.
!
COMMON LISP Graphics Models Page 7
COORDINATE SYSTEMS
3.6 Normalized Device Coordinates (NDC)
This is a term commonly defined by the implementors of graphics
systems. Normalized Display Coordinates describe an idealized
graphics display device that has a square display and an aspect ratio
of 1 (meaning that a mathematical square is "displayed" as a square,
not a rectangle). Locations in this display are specified by
coordinates whose X and Y values can be floating-point numbers in the
range of 0.0 to 1.0, inclusive. The origin in the NDC system is at
the lower left of the display.
By using Normalized Device Coordinates, all graphics data is mapped
into NDC space before mapping to the physical device. In the Graphics
Kernel System (GKS), NDC space provides both a device-independent
coordinate mapping and a graphical composition layer.
!
COMMON LISP Graphics Models Page 8
TRANSFORMATION
4 TRANSFORMATION
Transformation (or coordinate transformation) is the one-to-one
mathematical mapping of points in one coordinate system to those in
another. In the current context, transformation is limited to linear
operations of scaling, rotation, and translation. Projection (mapping
of an N-dimensional space onto N-1 or fewer dimensions) is not treated
in this document. The remaining discussions are therefore limited to
two dimensions, although nothing in the design should prohibit a user
from defining N-dimensional transformations and implementing his own
projection algorithms for treating higher dimensional graphics.
See Chapter 7 of "Fundamentals of Interactive Computer Graphics"
(Foley and Van Dam) for a thorough discussion of coordinate
transformations in graphics systems.
4.1 Rotation
Rotation is the mapping of points (x,y) to points (x',y') by the
equations
x' = x * cos(a) - y * sin(a)
y' = x * sin(a) + y * cos(a)
where a is the angle of counterclockwise rotation. Visually, the
entire picture is rotated by the angle a. Rotation is always computed
around the coordinate origin. Aspect ratio is always preserved under
a rotation transformation.
4.2 Scaling
Scaling is a mapping of points (x,y) to points (x',y') by the
equations
x' = x * x←factor
y' = y * y←factor
where x←factor and y←factor are constant terms. Visually, scaling
produces an enlargement or diminishment of the plotted data along
either axis. Aspect ratio (the ratio of the sizes of the x and y
axes) is preserved only when x←factor = y←factor.
4.3 Translation
Translation is the mapping of points (x,y) to points (x',y') by the
equations
!
COMMON LISP Graphics Models Page 9
TRANSFORMATION
x' = x + x←offset
y' = y + y←offset
where x←offset and y←offset are constant terms. Visually, the entire
picture is moved intact to another location.
5 TRANSFORMATION OPERATIONS
5.1 Matrix Representation
All points in the graphics system are represented in homogeneous
coordinates. Therefore, all transformations in N-dimensional space
may be represented by an (N+1)-dimensional square matrix. The actual
mapping of points (x,y) to points (x',y') may be carried out using the
following equation:
[x', y', 1] = [x, y, 1] * | r11 r12 0 |
| r21 r22 0 |
| t1 t2 1 |
which reduces to two equations involving a total of four multiply and
four add operations.
Transformations in COMMON LISP will be treated as LISP objects which
may contain these specialized N-dimensional matrices. A
transformation object can be created by specifying a window-viewport
pair and adding rotation information, if any. The user will also be
allowed to create transformation objects to suit his own needs. This
latter capability is important, since the window-viewport
transformation only produces scaling and translation without any
rotation capability. Also, the transformation manipulation functions
will accept N-dimensional transformation objects and are likely to be
more efficient than user-written matrix multiplication code.
A transformation object may also be defined which involves a
user-written function that will be called when a transformation is
required. This feature may be used to allow users to write
3-dimensional projection and clipping transformations.
5.2 Window-Viewport Transformation
A window is a rectangle whose limits (vertices) are defined in a set
of coordinates which may lie in application data space or in some
defined composition space. Conceptually, a window functions like a
"window" in the real world (the glass variety). It opens a
rectangular area in some coordinate space so that any data which falls
within the limits of the window may be made visible to the user. A
window may specifically delete data that falls outside its limits; in
this case it is a clipping rectangle (see Clipping Rectangle, below).
If clipping is not enabled, data that falls outside the window may
!
COMMON LISP Graphics Models Page 10
TRANSFORMATION OPERATIONS
still be visible.
In conjunction with a viewport, a window is used to provide a scaling
and translation transformation. This is a conventional method in
graphics to specify a coordinate transformation.
A viewport is a rectangle whose limits are defined in a coordinate
system that must lie in some defined composition space. The viewport
serves two functions:
o It defines where in the composition space the data or other
information will appear.
o When associated with a window, it defines a coordinate
transformation specification and also indicates that data
"seen through" that particular window will appear in the
viewport.
5.3 Active Transformation
All graphics operations must be applied with respect to some
transformation. For example, a line is drawn by specifying the end
points of the line. The coordinates of these points may be
transformed into the master system of some object which is being used
in a composite display, or directly into the picture area of a virtual
display. In the first case, the transformation may be an elaborate
one which includes multiple levels of scaling and rotation. The
latter may only involve a simple translation of points relative to the
origin of the logical device coordinates.
All of the output functions which require positioning information,
such as line drawing and character insertion, will take an optional
transformation argument. The default value of this argument will be
the currently specified active transformation. The active
transformation is no different from any other transformation except
that it has been designated to be the default transformation for
output operations. The system should provide a function similar to
the COMMON LISP IN-PACKAGE function which sets the value of a special
variable which is the active transformation. In addition, the system
may have a macro (WITH-TRANSFORMATION) which binds the value of the
current transformation within some scope.
6 CLIPPING RECTANGLE
A clipping rectangle is a rectangle defined as a window either in
application data space or in a composition space. Clipping is part of
the transformation operation. It is usually done in the originating
coordinate system. The purpose of clipping is to remove from the
display any portions of a graphical image that lie outside the
clipping rectangle. Thus, if the user specification of a line has end
!
COMMON LISP Graphics Models Page 11
CLIPPING RECTANGLE
points which are outside the rectangle and clipping is enabled, only
the portion of the line that falls within the rectangle will be mapped
onto the destination composition space. If clipping is not enabled,
the entire line will be mapped.
In the destination coordinate system, clipping is performed only at
the boundaries of the physical device. (A viewport cannot define a
clipping rectangle.) Since physical device coordinates are a bounded
coordinate system, any points which lie outside the bounds of the
physical device will be unconditionally clipped.
Clipping can be enabled or disabled on a global basis or for each
graphical output operation.
7 COMPOSITION
Composition is the process of building complex graphical objects from
(potentially) a number of different objects and coordinate systems.
Conceptually, composition is akin to placing various graphical objects
onto some flat surface in a particular arrangement. This flat surface
is termed a composition space. Windows can then select portions of
this flat space either for viewing on the screen or for use in other
composition spaces.
A simple example of composition is the definition of the symbol for a
NAND gate. The symbol is created in its own master coordinates. It
is then mapped onto various parts of another composition space and
lines are drawn using a different transformation into that composition
space to connect the symbols into a circuit diagram.
7.1 Composition Space
A composition space is an independent data space which has certain
special characteristics:
o It can store graphical objects.
o It can optionally define a rectangle which may be used
simultaneously as a window, a viewport, and a clipping
rectangle.
Mapping from application data space or from a composition space onto
another composition space is accomplished by specifying either a
window-viewport pair (plus rotation) or by explicitly providing source
and destination spaces plus a transformation matrix and a clipping
rectangle.
Portions of a composition space can be further mapped onto other
composition spaces to an arbitrary depth; and composition spaces can
be recursively mapped to themselves. When a composition space is
!
COMMON LISP Graphics Models Page 12
COMPOSITION
mapped onto other composition spaces, changes made in the original
composition space appear in all the composition spaces it is mapped
onto. By contrast, the contents of a composition space can be copied
to other composition spaces. Any subsequent changes made in the
original composition space will not be reflected in the copies.
7.2 Segments
"Segment" is a term used in conventional graphics systems to denote an
independently specified graphical object. Segments are built in
independent composition spaces. Segments may be used together with
other graphical objects and primitive operations to create a more
complex graphical object.
The creation and use of segments is entirely analogous to the
segmentation of programs into subroutines which may be used repeatedly
by different code segments. The building process is not confined to a
single level. Segments may be composed of other segments and the
entire object then used as a portion of a larger diagram. The
graphics system handles the nested coordinate transformations
necessary to produce the levels of graphical object.
A significant feature of a segment is that it is created once and may
then be mapped (via additional transformations) any number of times
into different composition spaces. An example of a segment is the
symbol for a NAND gate. This symbol need only be defined once. It
can then be mapped any number of times to create a circuit diagram.
Note that if the original NAND gate symbol is changed, all the
mappings of it automatically change. Furthermore, any change to a
transformation between one space and another propagates into any
further mappings. For example, if the window surrounding the NAND
gate segment is made larger, the NAND gate will appear to shrink in
each viewport mapped to that window. The graphics system handles all
intermediate levels of coordinate transformation needed to map the
segments.
Segments may be copied rather than mapped, in which case they lose
their reference to the original object. Changes in the original will
not affect any copies made from it.
Segments may be returned as the result of a pick operation (see
Pointing and Picking).
7.3 Virtual Display Composition
Since virtual displays are themselves composition spaces (see Virtual
Displays), they can be mapped onto other composition spaces. This is
particularly useful when making a virtual display that is a composite
of other virtual displays. Such a composite display can be treated as
a single display for display management purposes, and yet each display
!
COMMON LISP Graphics Models Page 13
COMPOSITION
can retain its own identity for all other operations. Some systems
call this a "pane" system with the final composite display called a
"frame."
7.4 COMMON LISP Composition Levels
COMMON LISP should allow for creation of arbitrary levels of
composition. One that will be provided by default is:
o Virtual display space (allowing virtual displays to be mapped
into the picture area of another virtual display)
8 ATTRIBUTES
Attributes are parameters that affect the visual representation of
output operations. They can, for example, determine the background
color of a composition space, the width and pattern of a line, the
font and spacing of text, or the visibility of a graphical object
mapped onto some composition space.
Some attributes are inherently "static" while others are inherently
"dynamic." When dynamic attributes are changed, the visual results of
previous operations that used those attributes will immediately
change. Operations done with static attributes must be re-executed in
order to change the visual appearance of their results.
Some attributes are naturally associated with types of operations
(such as graphics primitives) while others are associated with objects
(such as composition spaces). Some can be associated with both
objects and operations. For example, a composition space can have an
attribute that specifies the default color of all operations that take
place within it, and an individual graphics operation can specify a
color attribute to override the default.
Attributes are also organized in blocks. (GKS calls attribute blocks
"bundles.") Attribute blocks can be associated with individual
operations, transformations, or composition spaces. Nesting of
transformations implies some form of attribute nesting as well.
8.1 Attribute Descriptions
Attributes can be categorized by the type of operation or object they
affect, although this categorization is more for conceptual
convenience than to suggest a meaningful difference between the
attributes. The following is a suggested list of categories for
COMMON LISP attributes:
Composition space
!
COMMON LISP Graphics Models Page 14
ATTRIBUTES
Graphics
Text
Attributes associated with a composition space serve two functions:
they describe attributes of the composition space itself, and they
also provide a complete set of default attributes for any graphics or
text operations done into that space. These defaults can be
overridden by attributes applied to individual graphics or text
operations.
The following possible attributes which will be considered for
inclusion in a possible COMMON LISP graphics model are listed under
the categories described above. These attributes are all described in
terms of bitmapped terminals. Some of the attributes may function
differently - or not function at all - on other types of terminals,
such as character terminals. The specific behavior of each attribute
on various terminals is implementation-dependent.
o Composition Space Attributes - the first two attributes
determine characteristics of the composition space itself,
while the second two establish defaults for graphics or text
operations done in the space.
- Visibility - specifies whether operations done into this
space (when it is mapped into some other composition
space) will be immediately visible or deferred until a
later time.
- Background Color - specifies the background color of the
composition space.
- Drawing Color - specifies the default color to be applied
to all output operations into this space.
- Writing Mode - specifies the relationship applied to an
output operation and the existing bitmap pattern to
produce the resulting display rendition:
NIL - operation is performed (information is kept in
the display list) but the output display is not
changed.
:XOR, :OR, :ORC1, :AND, :ANDC1 - the Boolean
operation that is applied to the bitmap pattern of
the operation and the existing bitmap pattern to
produce the displayed result. The C1 forms mean
that the bitmap produced by the operation is first
complemented before the logical operation is
performed with the existing bitmap.
:REPLACE, :COMPLEMENT-REPLACE - the result of the
operation (or its complement) completely replaces
the affected contents of the display.
!
COMMON LISP Graphics Models Page 15
ATTRIBUTES
:ERASE, :COMPLEMENT-ERASE - the result of the
operation is completely replaced with the background
color (or its complement) of the composition space
o Graphics Attributes - these attributes are associated
specifically with graphics operations. They can also be
applied to a composition space to determine defaults for
graphics operations in that space.
- Line Width - specifies the width of a displayed line
expressed as a (floating-point) multiple of the minimum
width that the device can draw.
- Line Style - specifies the particular visual style of the
line to be drawn. The following are suggested although
implementations may vary in the types available:
:SOLID
:DASHED
:DOTTED
:DASHED-DOTTED
- Fill - specifies whether or not objects are to be filled,
the fill pattern to use, and the fill reference point.
- Marker Symbol - specifies the visual symbol used by the
graphics operations which place marker symbols at points.
The symbol is centered on the specified point. Supplied
symbols are implementation dependent.
o Text Attributes - these attributes are associated
specifically with text operations. They can also be applied
to a composition space to determine defaults for text
operations in that space.
- Font - specifies the font set to be used when writing
text. Values are implementation dependent.
- Character Spacing - alters the normal spacing of
character writing. This attribute is expressed as a
floating-point number that is multiplied by the character
height to produce additional space to be inserted between
characters. The number can be negative, in which case
characters may be forced closer together or overlapped.
- Character Slant - slants fonts to produce italics. The
slant is expressed in degrees and should be in the range
of -45 to +45.
- Base Line Angle - specifies the angle of writing
characters. This attribute is expressed as a
floating-point number representing degrees of rotation
from the normal horizontal. Unslanted characters will
!
COMMON LISP Graphics Models Page 16
ATTRIBUTES
always appear to be vertical when viewed from an angle
parallel to the base line.
- Text Path - specifies the direction of character writing
in relation to the base line. There are four possible
values:
:FORWARD - this is the normal left-to-right display
of characters in a direction parallel to the base
line.
:BACKWARD - this is the reverse of the :FORWARD
direction and is used, for example, when writing
Hebrew text.
:UP - characters are displayed sequentially "above"
each other in relation to the base line.
:DOWN - the reverse of :UP; characters are displayed
sequentially "below" each other in relation to the
base line.
- Texture - a bitmap pattern which is logically ANDed with
a character bitmap before writing to the display.
An implementation is free to designate supported attributes and to
categorize any supported attributes as static or dynamic.
8.2 Attribute Inheritance
Every composition space has a default attribute block associated with
it. This block must contain a complete specification of all the
supported attributes for an implementation. In general, these
attributes may be overridden on a per-operation basis.
A set of operations into some composition space may be performed with
respect to some other attribute block. This block may be incomplete.
Any required attribute values will be taken either from an explicit
value in a specific operation or from the default attribute block.
Attribute inheritance in the presence of multiple levels of
composition is not well understood. Static attributes may be treated
easily since the visual results of a performed operation cannot be
changed without re-executing the operation. Proper inheritance of
dynamic attributes, however, is more difficult to determine. At this
point, the inheritance of dynamic attributes is implementation
dependent.
!
COMMON LISP Graphics Models Page 17
VIRTUAL DISPLAYS
9 VIRTUAL DISPLAYS
A virtual display is a specialized graphical object used to display
graphics or text information on a physical device. It is the only
type of graphics object which can be displayed on a device.
A virtual display is made visible on a device by associating it with
that device, although a virtual display can exist without being
associated with any device. Associating a virtual display with a
device is similar to, but not the same operation as, creating a
mapping from one composition space to another. A major difference is
that virtual displays are opaque; that is, the order of association
affects the visible result on the device. If two virtual displays
overlap on the screen, the portion of the first which is overlapped by
the second will not be visible. Normal mappings onto composition
spaces are transparent, that is, all operations are always visible
(see Display Management).
Creation of a virtual display creates a composition space onto which a
number of graphical objects are mapped. These objects have default
spatial relationships which can be altered at the time the virtual
display is created. The following diagram illustrates the objects of
a virtual display in a typical configuration. All objects except the
picture area are optional.
Banner +--------------------------+
area | Banner area |
origin->+--------------------------+
============================<--+
= = |
= +----------------------+ =<--Borders
= | | =
= | Picture area | =
= | | =
= | | =
= | Picture area | =
= | origin | =
= |/ | <--Margins
= +----------------------+ = |
= <--+
+->+===========================
|
Virtual display origin
Each of the objects shown will be discussed in greater detail later in
this section.
The mapping of a virtual display's objects into its composition space
produce transformations which can be used during I/O operations.
Additional arbitrary transformations into this composition space can
be created as needed.
!
COMMON LISP Graphics Models Page 18
VIRTUAL DISPLAYS
To create a virtual display, one specifies the size of its picture
area along with the size and spatial relationship of any optional
parts. The total size of the virtual display is the size of the
picture area as extended by the optional parts.
9.1 Composition Space
The creation of a virtual display results in the creation of a
composition space within which the virtual display is built. This
space may be used in all respects as any other composition space;
users can do arbitrary graphical operations within it.
9.2 Picture Area
The picture area of a virtual display is the rectangular area where
data is normally displayed. It is a window-viewport pair which maps a
portion of application data space into the composition space of the
virtual display. The size of the viewport is the size specified when
the virtual display was created. By default, the window is the same
size and has the same coordinate system as the viewport; thus, the
transformation is trivial. A different window may be specified when
the display is created. Unless otherwise specified, the picture area
viewport has a coordinate origin at the lower left corner and a size
expressed in virtual display units (centimeters). The picture area
has a transformation object which may be used as the active
transformation in any graphics operation.
The other objects of a virtual display are placed in a fixed spatial
relationship to the sides of the picture area. If the picture area
grows or shrinks, the margins, border, and banner area move on the
screen to maintain this relationship.
9.3 Banner Area
The banner area is an optional part of a virtual display. It is
similar to the picture area in that it is defined as a window-viewport
pair. The viewport is mapped into the composition space in a
particular spatial relation to the picture area. It may be above,
below, or to the right or left of the picture area. It is separated
from the picture area by the width of the margin and border. Unless
otherwise specified, the banner area viewport has a coordinate origin
at the lower left corner. Its width (or height if the banner is to
the right or left) is, by default, the width (or height) of the
picture area viewport plus the width of any margins and borders. The
banner area has a transformation object which may be used as the
active transformation in any graphical operation.
!
COMMON LISP Graphics Models Page 19
VIRTUAL DISPLAYS
9.4 Border
A virtual display may optionally have a border. The border is an
outline of the picture area, separated from the picture area by the
margins. Its width is specified in virtual display units. In its
most basic form, the border may be a line of some default width
surrounding the picture area. If supporting hardware permits, it may
have an arbitrary thickness and tile pattern (see Bitmaps). The
border may be designated as a sensitive area for the pointing system.
9.5 Margin
The margin is the space between the border and the picture area; there
can be four margins associated with a virtual display. Its size is
measured in virtual display units. The default size of any margin is
implementation dependent.
Margins are most often used to separate text from the border.
However, some set of implementation dependent operations may also be
performed in the margins of a display, such as drawing lines for
scroll bars. The margins lie outside the coordinate system of the
picture area; they must be accessed by using the coordinate system of
the virtual display composition space.
9.6 Virtual Display Window
The entire rectangle encompassing the picture area, banner, border and
margins of a virtual display is enclosed in a window in the virtual
display composition space. This window may be used to map the display
onto a physical device or into some other composition space. The size
of this window tracks the "size" of the virtual display, such that if,
for example, the picture area viewport is changed, the virtual display
window is automatically adjusted.
9.7 Device Viewport
A device viewport is a specification, in logical device coordinates,
of the size and location of a virtual display on a physical device.
Unless otherwise specified, the size of a device viewport is the same
size as the virtual display window. The transformation is then a pure
translation. An arbitrary transformation may be applied to scale and
rotate the appearance of the virtual display on the screen.
9.8 LISP Terminal Streams To Virtual Devices
A virtual display may be used as an argument to the various varieties
!
COMMON LISP Graphics Models Page 20
VIRTUAL DISPLAYS
of MAKE-STREAM functions that exist in COMMON LISP. Such a stream can
be input, output, or both. A virtual display stream opened for output
means that printed LISP output will be directed to that virtual
display. An input stream designation means that a LISP read operation
on that stream will get input from the keyboard device attached to the
terminal. An input-output stream reads characters from the keyboard
and echoes those characters in that virtual display. All designation
of font, spacing, color, etc. is specified in attribute blocks
associated with that virtual display.
The physical device need not be a keyboard, although that is the
normal device. It may be any device capable of responding correctly
to the COMMON LISP input operations. This allows, for example, a file
to be associated with one display and the keyboard with another. The
resulting effects on the screen (and to the program) depend only on
the choice of virtual display used in the input operation.
9.9 Input Cursor
Each virtual display which has an associated virtual input device will
have an input cursor defined. The nature of this cursor is
implementation dependent but it must at least provide an indication,
when this display is being used for input, of the current location
where echoed input will appear. This cursor is often distinct from
the pointing (or mouse) cursor.
10 POINTING AND PICKING
In a virtual display and graphics environment, it is often necessary
to translate a visually perceived location on the display device into
information useful to the running program. Operations such as
selecting an item from a menu, indicating a virtual display to bring
to the top of the stacking order, and selecting a gate connection in a
circuit diagram are all examples of pointing or picking.
Pointing and picking are input operations that require a certain level
of physical device support. The device must be capable of generating
a visual indicator (cursor) which indicates a screen position, and it
must have a means of manipulating the position of this indicator. The
manipulation need not be independent from the host processor. For
example, the arrow keys on a character-oriented terminal might be used
to request the host processor to move the cursor to different spots on
the screen. Other supporting devices can be various forms of mouse,
light pen, tablet and cross-hair.
The distinction between pointing and picking is in the nature of the
object returned as a result of the operation. The result of a
pointing operation is always an N-dimensional (usually 2) coordinate.
The result of a picking operation is a previously defined graphical
object. This might be a simple object such as a line or it might be a
!
COMMON LISP Graphics Models Page 21
POINTING AND PICKING
composition space which makes up a part of the display.
A pointing or picking operation is always performed with respect to
some transformation. This transformation is used to specify both the
coordinate system in which the results are expressed and the level of
detail required of the operation. For example, a pick might return a
particular mapping of a NAND gate symbol, the NAND gate composition
space, or a portion of the NAND gate symbol, depending on the chosen
transformation.
Both pointing and picking are primarily input operations but may also
involve placement of the position cursor using the appropriate
coordinate system. The input operations are completed in a
device-dependent fashion, such as clicking a mouse button or pressing
a function key on the terminal.
Rectangular sections of the screen can be made sensitive to the
pointing cursor. Section 11.2 discusses this concept.
10.1 Pointing
Pointing is an input operation that returns a coordinate in some
N-dimensional space. The space must be previously defined. For
example, the coordinate may be an X-Y pair of physical device
coordinates. It may also be a coordinate in the master coordinate
system of some defined graphical object.
10.2 Picking
Picking is an input operation that returns a previously defined
graphical object. Such an object might be an entire virtual display,
for instance, when selecting a display to bring to the top of the
stacking order. It might also be some component of a graphical
object, such as a point, a line, or a segment.
11 DISPLAY MANAGEMENT
"Display management" refers to the facilities available for
controlling the appearance of the physical screen and making virtual
displays visible to the user. Since virtual displays are opaque when
placed onto a physical screen, they behave like cards stacked on a
table. Portions of the screen that are covered by the rectangle of a
virtual display are not visible while that display is visible. Thus,
a virtual display may hide (or "occlude") portions of other virtual
displays which were already on the screen. The display management
system must have the capability to place virtual displays on the
screen and remove them from the screen. The system must also be able
to move virtual displays on the screen and change their stacking
!
COMMON LISP Graphics Models Page 22
DISPLAY MANAGEMENT
order.
Other display management capabilities arise from the necessity to
provide a flexible and powerful user interface. Since the display
system should have some type of pointing device, the display
management system must allow the programmer to define all or portions
of a virtual display as being sensitive to the pointing device. This
means the the user's software can detect whenever the pointing device
enters or leaves some selected area of a virtual display. The system
must also provide for normal terminal I/O to be performed to and from
a virtual display.
11.1 Visibility And Stacking
A virtual display is a graphical object which may become visible on a
terminal screen. It can exist without being associated with any
device or it may be associated with several devices simultaneously.
The display management system remembers the order in which displays
are associated with each device. Associating several displays with a
device is called "stacking" since it is analogous to stacking up cards
on a flat surface; the order in which displays are associated with a
particular device is called that device's "stacking order." The
position of a display in the stacking order can be altered. It can be
brought to the top, pushed to the bottom, or placed above or below
another virtual display in the stacking order. If a display is moved
on the display screen, it maintains its position in the stacking
order.
The stacking order is important to the appearance of the screen,
because it helps determine which displays can hide other displays. A
virtual display is said to be "occluded" on some device if it is
beneath another virtual display in the stacking order for that device
and if some or all of its area is within the screen area occupied by
the other virtual display.
A virtual display, in addition to being associated with a device, may
also be "exposed" (rendered visible) or "unexposed" (rendered
invisible) on that device. In order for a virtual display to be
visible to the user on some device, it must be associated with that
device, be exposed, and not be entirely occluded by other exposed
virtual displays. A display can be made invisible but preserve its
position in the stacking order by making it unexposed. In this state,
it cannot occlude other virtual displays.
Exposure is a property of an element (virtual display) in a particular
stacking order, not a property of the element itself. Since each
display device has its own stacking order, a display may be associated
with more than one device but be exposed on only some of the devices.
!
COMMON LISP Graphics Models Page 23
DISPLAY MANAGEMENT
11.2 Sensitive Regions
Rectangular areas of a virtual display may be made sensitive to the
pointing device. A sensitive region is defined in virtual display
coordinates by specifying the lower left corner and the height and
width of the rectangle.
Designating a region as sensitive provides the programmer with several
capabilities for creating a user interface to the display system:
o The visual appearance of the sensitive region can be altered
either automatically when the pointing device enters or
leaves the region, or under program control without the
pointer moving at all.
o A LISP function can be invoked asynchronously when the
pointing device enters or leaves the region.
o The sensitive region can be returned as the result of a user
selection among a list of sensitive regions.
11.3 Menus
All display management systems should provide for a special type of
virtual display called a "menu." There can be many types of menus, but
one kind should be provided with all Common LISP systems. This is a
simple choice menu. The display appears as a vertical list of
options. The pointing device is used to point to a desired item and
the item is selected in an implementation-dependent fashion. There
must be LISP functions which allow the programmer to create the menu
(providing both the selectable items and the value to be returned from
selection of each item) and to display the menu and query the user for
an item selection. All of the usual display management functions
operate correctly on menus.
11.4 Pointer And Selection
Each implementation must provide a method for the user to "point" at a
particular location on the physical screen. This might be implemented
with a mouse, light pen, cross hairs, or the cursor movement keys of a
simple video terminal. This pointer should be able to indicate all
visible areas of the screen.
There must be a defined method of indicating to the display system
that some selection has been made relative to the pointing device.
The most common of these is the buttons on a mouse. It may also be
one or more special keys on the keyboard of the terminal device. Each
implementation must define the number of selection possibilities and
the method for invoking each.
!
COMMON LISP Graphics Models Page 24
DISPLAY MANAGEMENT
Each implementation must also provide some way of indicating that the
pointing device has moved.
12 BITMAPS
Many video terminal devices operate by allocating fixed-sized blocks
of display space (cells) for display of character and graphical data.
These cells are individually addressable and are the smallest
addressable unit from the programmer's perspective. Other graphics
devices are capable of doing direct vector and other graphic
operations on the display. Bitmapped terminals allow the programmer
to access individual pixels in the display directly. The method of
access is to maintain a two-dimensional array of bits in memory that
directly controls the display of each pixel. The array is called a
bitmap. All operations to the terminal display are made by altering
the bitmap.
In any implementation that supports bitmapped devices, each virtual
display will have a bitmap and each device will have a device bitmap.
It will be possible to retrieve all or portions of any of these
bitmaps via implementation-supplied functions as well as to create
bitmaps as LISP objects. Functions will exist to do arbitrary
operations combining bitmaps (OR, AND, etc.). These operations are
not clearly defined at this time. Suggestions appreciated. The
purpose of such bitmap operations is to provide special visual effects
such as shading and texturing.
∂09-Jan-85 1420 @MIT-MC:Henry%MIT-OZ@SCRC-RIVERSIDE Silence breaker
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 9 Jan 85 14:19:18 PST
Received: from MIT-APIARY-3 by MIT-OZ via Chaosnet; 9 Jan 85 17:17-EST
Date: Wed, 9 Jan 85 17:17 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-RIVERSIDE.ARPA>
Subject: Silence breaker
To: Cl-Windows@SU-AI.ARPA, Cl-Object-Oriented-Programming@SU-AI.ARPA,
Cl-Graphics@SU-AI.ARPA
As some of you may know, I am working on a kit for building menu-driven
graphical interfaces [such as document illustrators, circuit diagrammers,
etc.] called EzWin. The kit provides protocols for representing menu commands as
objects, mouse sensitivity and selection of graphical objects. It also tries to
separate the functionality of commands from the interface techniques and allow
alternative interaction styles. It is at a level considerably above the "just
bits on the screen" one at which Boetje@Dec's proposal is aimed, but would be
complementary to such proposals. A wide range of interesting graphical interfaces
is easily specifiable using this approach. I hadn't designed it with a "language
standard" in mind, but perhaps standardizing things at this level as well might
productive, promoting portability of interfaces.
I am currently preparing a paper on it for SigGraph '85. Interested people can
send me a message with US Mail address for a copy. It is too long for
transmission on this list and has many pictures.
∂20-Mar-85 2048 DDYER@USC-ISIB.ARPA ANSI windows
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 20:48:16 PST
Date: 20 Mar 1985 20:44:48 PST
Subject: ANSI windows
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
This tidbit is forwarded from WORKS digest
From: lef@nlm-vax.ARPA (Larry Fitzpatrick)
Subject: Alleged push for ANSI windows standard
Date: 5 Mar 85 23:28:58 GMT
Back in December, PC Week ran an article stating that several
companies(*) were banding together to push for a standard
"graphically oriented windowing environment". Standard, that is, for
the developer. My understanding (my need, in any case) is that this
would provide a basic functionality for manipulating windows, etc. so
that the developer of an application would not have to get involved
with the low-level screen manipulation.
I have heard of several packages that would act in this manner, some
of which are "coming soon" others which are out of reach(**, with the
possible exception of ALYS from Applix), none of which seem to come
close to being portable, let alone standard.
Does anyone know of:
a) any activity in this area by the companies in *?
b) any activity in this area by anyone not previously mentioned?
* - Microsoft, DRI, Intel, Apollo, Masscomp, Sun Micro Sys, Olivetti,
Motorola, Nova Graphics
** - Apple's Toolkit-32; GEM; ALYS from Applix; W/X/V packages from
groups at MIT and Stanford; does SunWindows fit the bill?; LOOPS?
-fitz
lef@nlm-vax
-------
∂20-Mar-85 2113 DDYER@USC-ISIB.ARPA ANSI windows (II)
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 21:13:22 PST
Date: 20 Mar 1985 21:10:51 PST
Subject: ANSI windows (II)
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
This information forwarded from WORKS digest
From: oblio!jon@topaz (Jon Steinhart)
Subject: Information on the ANSI windows work
Date: 9 Mar 85 22:41:01 GMT
ANSI X3H3 has formed a subgroup to investigate a possible window
standard. The group is currently examining various proposals to
determine what areas a window standard would address. The subgroup
chair is John Butler from Microsoft.
The best way to keep informed about the work on windows is to join
ANSI X3H3. Contact Barry Shepherd at IBM in Austin. Annual fees are
around $75. Don't expect the committee to magically "meet your
needs" and "do the right thing" without your help and input.
Jon Steinhart
Counterpoint Computers, Inc.
ANSI X3H3
-------
∂29-Jul-85 1235 Fischer.pa@Xerox.ARPA RE: Clearing the screen and other such things.
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 12:34:34 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 29 JUL 85 12:33:27 PDT
Date: 29 Jul 85 12:30 PDT
From: Fischer.pa@Xerox.ARPA
Subject: RE: Clearing the screen and other such things.
To: Common-lisp@SU-AI.arpa
cc: CL-windows@SU-AI.arpa
Message-ID: <850729-123327-2607@Xerox>
Its pretty clear that the CL-Windows group became disheartened when it
was reported that ANSI was working on a standard. This may not be the
case. One can hope it was actually a mass defection to the ANSI group,
but I doubt that.
Perhaps now that the subjec thas been warmed up to, and since not much
seems to have solved the problem in the interim, perhaps we can get
someone to describe what the state of the various "standards committees"
are.
There were two mentioned just before the CL-Windows group closed its
shutters, one was a band of rowdy manufacturers (including Microsoft,
DRI, Intel, Apollo, Masscomp, Sun Micro Sys, Olivetti, Motorola, Nova
Graphics) the other of couse ANSI.
Can anyone comment immediately on the state of these committees to the
CL-windows@SU-AI.arpa mailing list?
(ron)
∂29-Jul-85 2307 DDYER@USC-ISIB.ARPA Clearing the screen etc.
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 23:07:02 PDT
Date: 29 Jul 1985 23:05:33 PDT
Subject: Clearing the screen etc.
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: common-lisp@SU-AI.ARPA
cc: cl-windows@SU-AI.ARPA
Symbolics has adopted "window" in place of "screen" in its
naming conventions. I think this is the right thing, and is
superior to both "screen" and "terminal" except possibly in cases
where the display operation really does refer to a screen
or a terminal.
Also, with respect to naming, let me plug my preference; rather
than add a lot of DO-THIS-OR-THAT functions, I'd rather add ONE
function, which encapsulates all screen operations. I have in mind
the general form;
(displayop <<displaystream>> <<operation>> &rest args)
This general form permits all "window" operations to be
recognized trivially, permits generic and implementation specific
extensions, and permits both "flavorized" and "macroized"
implementations. It also has the advantage of not polluting
the language with a lot more random function names.
The CL-WINDOWS mailing list (which I theoretically moderate)
is pretty moribund, mainly from the inability to sustain a
conversation. I have a feeling that each of the CL
implementations is pretty set in its own way of handling
displays, and the efficiency issues, combined with the
extremely low-level nature of display drivers, make any
compromise agreement on "standards" for fully elaborated
displays unlikely. As such, I support the idea of
chipping off this piece of the problem.
-------
∂30-Jul-85 0915 STENGER%ti-csl.csnet@csnet-relay.arpa Re: Clearing the screen etc.
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 09:15:07 PDT
Received: from ti-csl by csnet-relay.csnet id aa16380; 30 Jul 85 12:07 EDT
Date: 30 Jul 1985 0938-CDT
From: Dan Stenger <STENGER%CSL60%ti-csl.csnet@csnet-relay.arpa>
Subject: Re: Clearing the screen etc.
To: cl-windows@su-ai.ARPA
In-Reply-To: Your message of 29-Jul-85 2305-CDT
Received: from csl60 by ti-csl; Tue, 30 Jul 85 10:01 CST
Date: 29 Jul 1985 23:05:33 PDT
Subject: Clearing the screen etc.
From: Dave Dyer <DDYER@USC-ISIB>
To: common-lisp@SU-AI
cc: cl-windows@SU-AI
Symbolics has adopted "window" in place of "screen" in its
naming conventions. I think this is the right thing, and is
superior to both "screen" and "terminal" except possibly in cases
where the display operation really does refer to a screen
or a terminal.
I agree with this. I think the term "window" is well accepted in the
lisp community and we should not try to change the consensus.
Also, with respect to naming, let me plug my preference; rather
than add a lot of DO-THIS-OR-THAT functions, I'd rather add ONE
function, which encapsulates all screen operations. I have in mind
the general form;
(displayop <<displaystream>> <<operation>> &rest args)
This general form permits all "window" operations to be
recognized trivially, permits generic and implementation specific
extensions, and permits both "flavorized" and "macroized"
implementations. It also has the advantage of not polluting
the language with a lot more random function names.
I don't think I agree with this totally. I think that windows should
be compatible with streams (maybe even a subtype of stream) and this
naming scheme doesn't fit with the currently defined stream functions.
(I would like to hear how others feel about windows as streams.)
Also I feel that we should maintain the current naming conventions
such as MAKE-WINDOW for creating a new window. If structures are used
for implementation of windows the automatically generated functions
would all need renaming in some way. However I do agree with your
goal of limiting the addition of a bunch of new function names.
The CL-WINDOWS mailing list (which I theoretically moderate)
is pretty moribund, mainly from the inability to sustain a
conversation. I have a feeling that each of the CL
implementations is pretty set in its own way of handling
displays, and the efficiency issues, combined with the
extremely low-level nature of display drivers, make any
compromise agreement on "standards" for fully elaborated
displays unlikely. As such, I support the idea of
chipping off this piece of the problem.
I guess I'm not quite as pessimistic. Agreeing on a standard for the
Lisp language was probably an even tougher job. Also after the
agreement was reached companies with existing Lisp implementations
(such as Symbolics) went to a lot of trouble and probably even
sacrificed some performance to support the standard. I know that TI
would be willing to support a reasonable Common Lisp window standard.
Dan Stenger
-------
∂17-Dec-85 2157 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 21:38:11 PST
Received: from tektronix by csnet-relay.csnet id ag21296; 17 Dec 85 21:43 EST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: cl-windows@su-ai.ARPA, cl-graphics@su-ai.ARPA
Received: from tekchips by tektronix with smtp ; 17 Dec 85 15:26:20 PST
Date: Tuesday, 17 Dec 85 15:16:03 PST
PL add me to your mailing list.
sridhar%tekchips@tektronix.csnet
∂16-Dec-86 1905 RICHER@SUMEX-AIM.STANFORD.EDU CL-WINDOWS mailing list
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 86 18:57:41 PST
Date: Tue 16 Dec 86 18:54:34-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: CL-WINDOWS mailing list
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12263390243.65.RICHER@SUMEX-AIM.STANFORD.EDU>
You are receiving this message because you are on one of two
distribution lists, soon to be merged. The first list is
CL-WINDOWS@SU-AI.ARPA which began in Fall 1984. I think this list was
started to discuss a Commonlisp Window Standard. Ignorant of this
list, but interested in a Commonlisp Window Standard, and more recently,
Commonlisp implementations (on lisp machines) or interfaces (on Unix
workstations) of/to X and NeWS (servers), with application programmer
libraries done in an object-oriented language (eventually something that is
compatible with the sometime-to-come CL object standard, supposedly
some variant of Commonloops), I set out to find other interested
individuals. There seems to be enough interest in these topics to
warrant a discussion list, but it seems appropriate to merge with the
existing CL-WINDOWS list. Because Dick Gabriel, the maintainer of the
CL-WINDOWS list agreed to this arrangement and in particular, felt
that discussion of lisp window systems related to the X, NeWS, and
Commonloops "standards" was appropriate on CL-WINDOWS, I am forwarding
the list of addresses I have recently collected to Dick and he will
add them to his list. Note that there have been no messages on the
list that I was thinking of starting. However, there have been messages on
CL-WINDOWS dating back to two years ago. (Below is a description of
CL-WINDOWS when it started.) I FTPED the archives from SAIL (=SU-AI)
and there are quite a few messages from the past. However, the last
message I found was Dec. 1985? I don't know if that is really the
last message or not? Anyhow, please contribute something stimulating and
intelligent wrt to these issues. If you do not want to be on this
list, (so sorry), and if you think I'm the culprit, then send me a
message and I'll forward to Dick. By the way there are other related
lists of possible interest:
xpert@athena.mit.edu
xport@athena.mit.edu
news-makers@brillig.umd.edu
cl-graphics@su-ai.arpa
common-lisp@su-ai.arpa
commonloops.pa@xerox.com
In each case, add -request and mail a request to get on (e.g.,
xpert-request@athena.mit.edu)
I do not maintain or moderate any of these lists.
Dick will maintain the CL-WINDOWS mailing list, but messages are not
filtered or digested at this point in time.
By the way I would suggest that places like Xerox and Symbolics which
have multiple addresses even on my list, set up a local redistribution
list. If someone can do that, forward the information to
cl-windows-request@su-ai.arpa.
-----------------------------------------------------------------------------
First message in Cl-WINDOWS, Fall 1984
Introduction
Welcome to the Common Lisp Window Subgroup.
In order to mail to this group, send to the address:
CL-Windows@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLWIND.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Windows-request@su-ai.arpa
-------
∂16-Dec-86 2254 RICHER@SUMEX-AIM.STANFORD.EDU purpose of mailing list
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 86 22:54:05 PST
Date: Tue 16 Dec 86 19:55:48-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: purpose of mailing list
To: "CLW:": ;
cc: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12263401391.16.RICHER@SUMEX-AIM.STANFORD.EDU>
I'm sorry if I haven't clarifed things well, and in case I didn't
I better make sure now before we merge the lists. My feeling was
that a lot of people interested in some combination of X/NEWS, Commonlisp,
COmmonloops are interested in sharing information, and maybe even
code with regard to what they are doing with these things. This is
different than the initial focus of CL-WINDOWS which was trying to iron
out a standard. I'm happy to see the info kind of list I envisioned
merged with the CL-WINDOWS "standards discussion" list, but I think we
need to make sure that's really a good idea in most people's minds.
Because the CL-WINDOWS messages seemed to have come to halt unless I
am mistaken, it sounds like some discussion about what people are
actually doing isn't a bad idea. But that means some detailed messages
perhaps about implementation related stuff being mixed with high-level
discussion about standards. If you think this marriage is a bad idea,
speak up now ... you should probably reply ONLY to me in most cases
since a lot of people might not care one way or the other.
Mark
-------
∂17-Dec-86 0556 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU X server implementors?
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86 05:56:20 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Dec 86 08:52-EST
Date: Wed, 17 Dec 86 08:50 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X server implementors?
To: xport@ATHENA.MIT.EDU, xpert@ATHENA.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
Message-ID: <861217085012.9.RWS@KILLINGTON.LCS.MIT.EDU>
If there is anyone out there contemplating implementing an X V11 server
in a language other than C, or as multiple processes, and is willing
to admit it (at least privately to me), I would like to talk with you.
∂17-Dec-86 2251 RICHER@SUMEX-AIM.STANFORD.EDU a bunch of messages on X/News & Commonlisp
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86 22:51:23 PST
Date: Wed 17 Dec 86 17:54:24-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: a bunch of messages on X/News & Commonlisp
To: "CLW:": ;
cc: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12263641434.77.RICHER@SUMEX-AIM.STANFORD.EDU>
The messages below were received as responses to one of two enquires:
(1) information on people using X, PCL, HP-CL, and GNU emacs on HP bobcats,
(2) query to people on xpert, common-lisp, and commonloops mailing list
about their interest and activites regarding Commonlisp/Commonloops
window systems interfaced to X (or NeWS).
I have only included responses that might be of general interest; mostly
explaining what people are doing. You might be interested to know that
the responses I have received including the just "add-me-to-the list" ones
not printed below include people using all sorts of hardware at all sorts
of places.
15-Nov-86 07:01:52-PST,1200;000000000001
Return-Path: <carter%silicon@utah-cs.arpa>
Received: from utah-cs.ARPA by SUMEX-AIM.ARPA with TCP; Sat 15 Nov 86 07:01:50-PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA03585; Sat, 15 Nov 86 08:03:18 MST
Received: by silicon.ARPA (4.30/4.40.2)
id AA01102; Sat, 15 Nov 86 08:10:36 mst
Date: Sat, 15 Nov 86 08:10:36 mst
From: carter%silicon@utah-cs.arpa (Tony M. Carter)
Message-Id: <8611151510.AA01102@silicon.ARPA>
To: richer@sumex-aim.arpa
Subject: X and CommonLisp
Cc: hucka@utah-cs.arpa, kessler%orion@utah-cs.arpa
We currently use hp-cl running as a subshell under gnu and are having good
success --- it is MUCH less painful than using NMODE. We are also in the
process of interfacing to the X library so that cl can handle windows, etc.
Some students are undertaking a project to construct a user-interface package
with mouse-sensitive objects. Unfortunately, we don't have CommonLoops yet,
so we are implementing on top of a local package we call frobs (frame objects)
which will permit us to do intelligent reasoning about objects as well. We
believe that frobs can be brought up on top of CommonLoops when it becomes
available.
Tony Carter (carter@utah-cs)
15-Nov-86 13:22:13-PST,1203;000000000001
Return-Path: <kessler%utah-orion@utah-cs.arpa>
Received: from utah-cs.ARPA by SUMEX-AIM.ARPA with TCP; Sat 15 Nov 86 13:22:11-PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA12899; Sat, 15 Nov 86 14:23:44 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA26810; Sat, 15 Nov 86 14:23:41 MST
Date: Sat, 15 Nov 86 14:23:41 MST
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
Message-Id: <8611152123.AA26810@utah-orion.ARPA>
To: RICHER@sumex-aim.arpa
Subject: X, GNU, and HPCL
That is exactly the configuration that we are running on most of our systems.
We usually run GNU with HPCL in GNU window and other windows with shells and
RLOGIN's to various machines. It works quite well. We also have a project
developing an combined objects and frame system called (FROBS). A group is
interfacing X window operations to FROBS.
Anyway, we have a new shell.el that makes gnu run the HPCL with gnu better.
Also, we have made a number of hacks to X to fix them (you might have seen
the messages). If you want further information, contact thomas@utah-gr.arpa
for X information, stoller@utah-orion.arpa for GNU information and maybe
mjb@utah-orion.arpa for HPCL help.
Bob.
16-Nov-86 10:51:14-PST,957;000000000001
Return-Path: <hearn%hilbert@rand-unix.ARPA>
Received: from rand-unix.ARPA by SUMEX-AIM.ARPA with TCP; Sun 16 Nov 86 10:51:09-PST
Received: from hilbert.arpa (hilbert) by rand-unix.ARPA; Sun, 16 Nov 86 09:33:17 pst
Received: by hilbert.arpa; Sun, 16 Nov 86 09:26:50 pst
From: Tony Hearn <hearn%hilbert@rand-unix.ARPA>
Message-Id: <8611161726.AA00250@hilbert.arpa>
To: Mark Richer <RICHER@sumex-aim.arpa>
Cc: hpai%hilbert@rand-unix.ARPA
Subject: Re: X and Commonlisp
In-Reply-To: Your message of Fri 14 Nov 86 14:05:56-PST.
<12254949090.12.RICHER@SUMEX-AIM.ARPA>
Date: Sun, 16 Nov 86 09:26:47 PST
We'd certainly like to share such information with you. As a matter of fact,
we are using PSL for most of our research rather than Common LISP, but the
X - GNU - lisp model remains the same.
If you make up a mailing list, add "hpai%hilbert@rand-unix.arpa" to it.
That reaches all interested parties here.
Thanks,
Tony Hearn
20-Nov-86 14:19:42-PST,925;000000000001
Return-Path: <sundar@hermes.ai.mit.edu>
Received: from hermes.ai.mit.edu by SUMEX-AIM.ARPA with TCP; Thu 20 Nov 86 14:19:29-PST
Received: by hermes.ai.mit.edu; Thu, 20 Nov 86 17:19:38 EST
Date: Thu, 20 Nov 86 17:19:38 EST
From: sundar@hermes.ai.mit.edu (Sundar Narasimhan)
Message-Id: <8611202219.AA05039@hermes.ai.mit.edu>
To: RICHER@sumex-aim.arpa
In-Reply-To: Mark Richer's message of Thu 20 Nov 86 11:57:55-PST
Subject: X and lisp graphics
Hi:
I would be grateful if you could forward to me any replies you get in
response to your query of integrating X and Lisp graphics. I started
on something like this some time ago, but have had to shelve it for a
while owing to other time constraints. What I have working is an
interface between X and Lucid lisp using Lucid's foreign call
interface but with a layer of flavors inbetween. I plan to finish it
sometime when I get the time to do it.
-Sundar.
20-Nov-86 15:24:28-PST,783;000000000001
Return-Path: <chris@columbia.edu>
Received: from columbia.edu by SUMEX-AIM.ARPA with TCP; Thu 20 Nov 86 15:24:23-PST
Received: by columbia.edu (5.54/1.14)
id AA02942; Thu, 20 Nov 86 18:25:19 EST
Date: Thu, 20 Nov 86 18:25:19 EST
From: Chris Maio <chris@columbia.edu>
Message-Id: <8611202325.AA02942@columbia.edu>
To: richer@sumex-aim.arpa
In-Reply-To: Mark Richer's message of Thu 20 Nov 86 11:57:55-PST
Subject: X and lisp graphics
Mark,
I'm glad to hear about the Utah effort to add X compatibility to the HP
Common Lisp, since I'm interested in doing the same thing for NeWS on the
Bobcat. I have no idea at this point whether we'll get beta-test status for
NeWS or how much help HP will provide us, but I'll let you know if I get
anywhere.
Chris
21-Nov-86 11:48:04-PST,1640;000000000001
Return-Path: <tsf@theory.cs.cmu.edu>
Received: from THEORY.CS.CMU.EDU by SUMEX-AIM.ARPA with TCP; Fri 21 Nov 86 11:47:57-PST
Date: Friday, 21 November 1986 14:48:01 EST
From: Timothy.Freeman@theory.cs.cmu.edu
To: Mark Richer <RICHER@sumex-aim.arpa>
Subject: Re: X and lisp graphics
Message-ID: <1986.11.21.18.58.41.Timothy.Freeman@theory.cs.cmu.edu>
In-Reply-To: <12256498649.76.RICHER@SUMEX-AIM.ARPA>
We have some code that uses X from Lucid (er, Sun) Lisp. However, it
only does characters, lines, and rectangles. It was written to be
downward compatible with another equally anemic, poorly-written piece
of code that ran on another machine. I can send it to you if you
want, but you should definitely use it as an example of working code
instead of as a foundation for code that you actually intend to use
for a long time.
I discovered documentation for X in the subdirectory doc of the X
distribution. It describes what routines to call from C to pop up
windows, draw lines, characters, and so forth. To get things other
than boring text from xterm, you have to deal with X directly. I will
mail you the documentation too, if you want, but you are probably
better off getting it directly from MIT.
If you do get a nice piece of code up and running, I would certainly
be interested in seeing it.
There has been some work on defining a standard graphics interface for
common lisp. You may want to post to the common lisp mailing list
asking for information about that sort of thing so you don't wind up
reinventing the wheel in such a way that your wheels are incompatible
with everyone else's.
9-Dec-86 17:25:48-PST,556;000000000001
Return-Path: <klee@ads.ARPA>
Received: from grape.ads.ARPA (ADS.ARPA.#Internet) by SUMEX-AIM.ARPA with TCP; Tue 9 Dec 86 17:25:45-PST
Date: Tue, 9 Dec 86 17:24:30 pst
From: klee@ads.ARPA (Ken Lee)
To: richer@sumex-aim.arpa
Subject: Re: X window system
Mark,
I am interested in CommonLisp interfaces to SunNEWS. Please add me
to your mailing lisp. I am doing applied research in the area of
object-oriented (flavors) interactive graphics tools for user interfaces
to LISP AI systems.
Ken Lee
Advanced Decision Systems
Mountain View, CA
9-Dec-86 19:31:38-PST,1627;000000000001
Return-Path: <FAHLMAN@C.CS.CMU.EDU>
Received: from C.CS.CMU.EDU by SUMEX-AIM.ARPA with TCP; Tue 9 Dec 86 19:31:30-PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 9 Dec 86 22:33:45-EST
Date: Tue, 9 Dec 1986 22:33 EST
Message-ID: <FAHLMAN.12261562345.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Cc: slisp@C.CS.CMU.EDU
Subject: X window system
In-reply-to: Msg of 9 Dec 1986 19:03-EST from Mark Richer <RICHER at SUMEX-AIM.ARPA>
Mark,
It looks like the standard workstation configuration around CMU is going
to be the Mach operating system, X, and Common Lisp -- our own Common
Lisp on the IBM RT's, and Lucid's Common Lisp on the microVaxen and
Suns. We will be developing a Common Lisp to X interface for our own
use, and would like to participate in any discussions leading toward the
standardization of this interface.
The whole Spice Lisp group here will be involved in this in one way or
another, so for now it is probably best just to add "slisp@c.cs.cmu.edu"
to your mailing list. If this becomes unwieldy, we'll change the
arrangements later.
We're probably not as far along in our knowledge of X as other groups --
we only received a version of X for the IBM RT this week, and don't yet
have it running under Mach. We do have some experience in building
hairy Common Lisp interfaces to other things, however.
Thanks for taking the initiative in setting this up. The sooner people
start talking, the less has to be undone in order to make everyone's
system compatible.
-- Scott
9-Dec-86 21:57:03-PST,726;000000000001
Return-Path: <ehl%cogsci.Berkeley.EDU@BERKELEY.EDU>
Received: from cogsci.berkeley.edu ([128.32.130.5].#Internet) by SUMEX-AIM.ARPA with TCP; Tue 9 Dec 86 21:56:50-PST
Received: by cogsci.berkeley.edu (5.57/1.17)
id AA22770; Tue, 9 Dec 86 21:57:39 PST
Date: Tue, 9 Dec 86 21:57:39 PST
From: ehl%cogsci.Berkeley.EDU@berkeley.edu (Edward H. Lay)
Message-Id: <8612100557.AA22770@cogsci.berkeley.edu>
To: richer@sumex-aim.stanford.edu
Subject: X & PCL
I am interested in being on your mailing list about X and PCL etc.
I am currently involved in porting the Boxer System to a Sun running
Common Lisp, PCL and possible X (we are still evaluating different
window systems.)
edward lay (ehl@cogsci.berkeley.edu)
10-Dec-86 08:24:27-PST,845;000000000001
Return-Path: <cagan%hplmrc@hplabs.HP.COM>
Received: from hplabs.HP.COM by SUMEX-AIM.ARPA with TCP; Wed 10 Dec 86 08:24:11-PST
Received: from hplms1 by hplabs.HP.COM ; Wed, 10 Dec 86 07:44:08 pst
Received: from hplmrc (hplmrc) by hplms1; Wed, 10 Dec 86 07:43:50 pst
Return-Path: <cagan@hplmrc>
Received: from hplmrc by hplmrc ; Wed, 10 Dec 86 07:43:20 pst
Message-Id: <8612101543.AA08480@hplmrc>
To: richer@sumex-aim.ARPA
X-Mailer: mh
Subject: CommonLisp/X Mailing List
Date: Wed, 10 Dec 86 07:42:06 PST
From: Marty Cagan <cagan%hplmrc@hplabs.HP.COM>
Mark,
We've implemented both a CL interface to Xlib, and a Common Objects
interface to the Xray lib. We've also been experimenting with
a CommonLoops (Classes) interface to Xlib. Can you put me on the
new mailing list please?
Thanks,
Marty Cagan (cagan@hplabs)
10-Dec-86 08:50:54-PST,677;000000000003
Return-Path: <rfb@h.cs.cmu.edu>
Received: from H.CS.CMU.EDU by SUMEX-AIM.ARPA with TCP; Wed 10 Dec 86 08:50:50-PST
Date: 10 Dec 1986 11:08-EST
From: Rick.Busdiecker@h.cs.cmu.edu
To: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Subject: Re: Windows in COmmonloops?
Message-Id: <534614920/rfb@h.cs.cmu.edu>
In-Reply-To: Mark Richer's mail message of Tue, 9 Dec 86 16:08:12 PST
I'm developing a customizable graphics editor in CommonLoops. Once the
SpiceLisp (now CMU CommonLisp) hooks to X are made (real soon) I will
be including X as one of the window managers that I support. It should
become the primary window manager for my development work before long.
Rick
10-Dec-86 21:12:03-PST,766;000000000001
Return-Path: <Rao.pa@Xerox.COM>
Received: from Xerox.COM by SUMEX-AIM.ARPA with TCP; Wed 10 Dec 86 21:11:55-PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 DEC 86 19:16:01 PST
Date: 10 Dec 86 19:15 PST
Sender: Rao.pa@Xerox.COM
To: RICHER@SUMEX-AIM.ARPA
From: RAO.pa@Xerox.COM
Subject: Re: Windows in COmmonloops?
Message-ID: <861210-191601-5020@Xerox>
Message type: Message
Topic:
Text:
Re: Message of Tue, 9 Dec 86 16:08:12 PST from Mark Richer
<RICHER@SUMEX-AIM.ARPA>
I'm doing my masters thesis at MIT on building a window system in
CommonLoops for Xerox Commonlisp. One of my goals is to be able to
build X easily on top of this window system.
Please add me to your distribution list.
ramana
rao.pa@xerox.com
15-Dec-86 12:15:18-PST,1299;000000000001
Return-Path: <cerys@XX.LCS.MIT.EDU>
Received: from XX.LCS.MIT.EDU by SUMEX-AIM.ARPA with TCP; Mon 15 Dec 86 12:14:32-PST
Received: from RTS-12.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Dec 86 15:18-EST
REPLY-TO: cerys@XX
FCC: vx:/usr/cerys/outgoing-mail
FROM: Dan Cerys <cerys@XX>
TO: Mark Richer <RICHER@SUMEX-AIM.ARPA>
SUBJECT: Re: X window system
DATE: 15-Dec-86 15:15:58
SENDER: cerys@XX
MESSAGE-ID: <cerys.2744050557@RTS-12>
Please add me to this list. Bob Scheifler has already done a V10 X
windows implementation for LISPM's. I've been talking to him about an
implementation for V11 of X windows on Explorers and Symbolics.
Dan
16-Dec-86 11:42:44-PST,811;000000000001
Return-Path: <lowry%bizet.DEC@decwrl.DEC.COM>
Received: from decwrl.dec.com by SUMEX-AIM.STANFORD.EDU with TCP; Tue 16 Dec 86 11:42:34-PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA20897; Tue, 16 Dec 86 11:45:26 PST
Message-Id: <8612161945.AA20897@decwrl.dec.com>
Date: Tuesday, 16 Dec 1986 11:39:20-PST
From: lowry%bizet.DEC@decwrl.DEC.COM (DAVID LOWRY 225-6290 BIZET::LOWRY)
To: richer@sumex-aim.ARPA
Subject: X window system
Hi, I'm writing the X window routines that will be included in
the next release of Vax Lisp. I would like to be put on your mailing
list for the common lisp X window distribution.
Who am I?
David Lowry
lowry%bach.dec@decwrl.dec.com
Digital Equipment Corporation
77 Reed Road HL02-3/C10
Hudson, MA 01749
Many Thanks.
DDL
17-Dec-86 06:07:47-PST,829;000000000001
Return-Path: <@SAIL.STANFORD.EDU:RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU>
Received: from SAIL.STANFORD.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Wed 17 Dec 86 06:07:46-PST
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86 05:56:20 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Dec 86 08:52-EST
Date: Wed, 17 Dec 86 08:50 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X server implementors?
To: xport@ATHENA.MIT.EDU, xpert@ATHENA.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
Message-ID: <861217085012.9.RWS@KILLINGTON.LCS.MIT.EDU>
If there is anyone out there contemplating implementing an X V11 server
in a language other than C, or as multiple processes, and is willing
to admit it (at least privately to me), I would like to talk with you.
-------
∂26-Dec-86 1428 RICHER@SUMEX-AIM.STANFORD.EDU [Ralph R. Swick <swick@ATHENA.MIT.EDU>: User Interface Toolkit proposal]
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 86 14:27:53 PST
Date: Fri 26 Dec 86 14:27:42-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: [Ralph R. Swick <swick@ATHENA.MIT.EDU>: User Interface Toolkit proposal]
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12265963100.15.RICHER@SUMEX-AIM.STANFORD.EDU>
If you are on the xpert mailing list you have seen the message forwarded
below. I am forwarding to cl-windows because I believe any proposed
user interface toolkit for X might be of interest to readers here
(that are not on xpert) and particularly because it can impact lisp
window systems to the degree that they support or are interfaced to X.
---------------
Return-Path: <swick@ATHENA.MIT.EDU>
Received: from ATHENA by SUMEX-AIM.STANFORD.EDU with TCP; Wed 24 Dec 86 09:29:56-PST
Received: by ATHENA (5.45/4.7)
id AA27342; Wed, 24 Dec 86 11:55:44 EST
Received: by LYRE (5.45/4.7)
id AA16343; Wed, 24 Dec 86 11:55:14 EST
Message-Id: <8612241655.AA16343@LYRE>
To: xpert
Subject: User Interface Toolkit proposal
Date: Wed, 24 Dec 86 11:55:02 -0500
From: Ralph R. Swick <swick@ATHENA.MIT.EDU>
A draft proposal for a user interface toolkit is available for ftp in
the pub directory on zap.mit.edu [18.72.0.126].
This document has resulted from an intensive effort on the part of
Digital Equipment Corporation and Hewlett-Packard Company to merge the
better features of the toolkits in the X.V10R4 distribution and
extract a common foundation upon which a variety of application
environments may be built. Their stated goal is to provide the next
higher level of common (portable) interfaces above Xlib.
M.I.T. has a goal to have available at least a preliminary version of
a user interface toolkit and one or more application environments (UIMS)
to be distributed with the first general distribution of X version 11.
The document "X Toolkit, A Proposed Architecture" is distributed for your
comment and to let you know one of the directions in which we are headed.
If we are to achieve the availability date as stated, the period during
which comments can be expected to have major impact on the implementation
is unfortunately very short. We do, however, invite those comments.
The list of individual contributors to this draft is already very long;
a future revision of a specification will give them the recognition
they deserve.
I hope that applications developers who need to use one of the
applications environments distributed with X version 10 release 4 will be
able to use this draft proposal to prioritize and partition their
development effort.
Ralph R. Swick
M.I.T. Project Athena
Swick@Athena.MIT.EDU
-------
∂26-Dec-86 1437 RICHER@SUMEX-AIM.STANFORD.EDU [kddlab!elis03@vc.sra.junet (Ken Seo): x-window in lisp]
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 86 14:37:14 PST
Date: Fri 26 Dec 86 14:37:00-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: [kddlab!elis03@vc.sra.junet (Ken Seo): x-window in lisp]
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12265964795.15.RICHER@SUMEX-AIM.STANFORD.EDU>
Those of you on xpert will probably vote to have me shot but here is
another forwarded message (I think the xpert msgs. of interest to cl-windows
will be very small in number so bear with this please):
---------------
Return-Path: <kddlab!titcca!vc!elis03@titcca.cc.titech.junet>
Received: from ATHENA by SUMEX-AIM.STANFORD.EDU with TCP; Fri 26 Dec 86 00:18:34-PST
Received: by ATHENA (5.45/4.7)
id AA06733; Fri, 26 Dec 86 02:33:11 EST
Received: from kddlab.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA14489; Fri, 26 Dec 86 02:31:42 EST
Received: by kddlabs.junet ; Thu, 25 Dec 86 21:40:15+0900
Received: by kddlabs.junet ; Thu, 25 Dec 86 21:40:07+0900
Received: by titcca.cc.titech.junet (4.12/6.2Junet)
id AA23323; Thu, 25 Dec 86 09:27:22 jst
Received: from vc.sra.junet by srava.sra.junet (4.13/6.2Junet)
id AA16646; Thu, 25 Dec 86 09:08:56 jst
Received: by vc.sra.junet (4.13/6.1Junet)
id AA05683; Thu, 25 Dec 86 09:07:39 jst
Date: Thu, 25 Dec 86 09:07:39 jst
From: kddlab!elis03@vc.sra.junet (Ken Seo)
Return-Path: <elis03@vc.sra.junet>
Message-Id: <8612250007.AA05683@vc.sra.junet>
To: kddlabs!xpert%athena.mit.edu@seismo.CSS.GOV
Subject: x-window in lisp
Dec. 25,1986
To whom it may concern,
In August of 1986, Jim Gettys posted the proposed revisions for
version 11 of X window on the net. I got it through the University
of Tokyo relay (here in Japan).
In the prologue, he added the fact that a lisp version of
X window would be finished in March of 1987.
I would like to know the present status of the lisp version of
X window. Also, which lisp dialog it is being written in.
Please send your answers to the following address;
elis03@sravc.sra.junet (via the u-tokyo.junet relay)
Thank you very much.
Yours truly,
Harlan Seo
address:
c/o SRA
Hirakawacho 1-1-1
Chiyoda-ku, Tokyo
Japan 105
Tel: (03)234-2623
e-mail: elis03@sravc.sra.junet
-------
∂26-Dec-86 1753 gabriel@vaxa.isi.edu cl-windows mailing list
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 86 17:53:13 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA05858; Fri, 26 Dec 86 17:39:34 pst
From: gabriel@vaxa.isi.edu (Gabriel Robins)
Message-Id: <8612270139.AA05858@vaxa.isi.edu>
Date: 26 Dec 1986 1739-PST (Friday)
To: cl-windows@sail.stanford.edu
Subject: cl-windows mailing list
Please add me to the list. Thanks,
Gabe
∂27-Dec-86 0958 ho@ucbarpa.Berkeley.EDU CL-windows
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 27 Dec 86 09:58:24 PST
Received: by ucbarpa.Berkeley.EDU (5.57/1.18)
id AA06079; Sat, 27 Dec 86 09:58:46 PST
Date: Sat, 27 Dec 86 09:58:46 PST
From: ho@ucbarpa.Berkeley.EDU (Kinson Ho)
Message-Id: <8612271758.AA06079@ucbarpa.Berkeley.EDU>
To: cl-windows@sail.stanford.edu
Subject: CL-windows
Please put me on the cl-windows mailing list. Thank you.
Kinson Ho (ho@ucbarpa.Berkeley.edu)
∂27-Dec-86 1556 wanginst!ulowell!ulowell.ULOWELL.EDU!grinstei@harvard.HARVARD.EDU please add me to the list
Received: from HARVARD.HARVARD.EDU by SAIL.STANFORD.EDU with TCP; 27 Dec 86 15:56:37 PST
Received: by harvard.HARVARD.EDU; Sat, 27 Dec 86 18:56:52 EST
Received: by wanginst.EDU (4.12/5.8.WangInst)
id AA03867; Sat, 27 Dec 86 17:54:44 est
Posted-Date: Sat, 27 Dec 86 15:21:00 EST
Received: by ulowell.ULOWELL.EDU (5.51/UUCP-Project/rel-1.0/12-23-86)
id AA18548; Sat, 27 Dec 86 15:21:00 EST
Date: Sat, 27 Dec 86 15:21:00 EST
From: wanginst!grinstei@ulowell.ULOWELL.EDU (Georges Grinstein)
Message-Id: <8612272021.AA18548@ulowell.ULOWELL.EDU>
To: cl-windows@sail.stanford.edu
Subject: please add me to the list
Cc: grinstein@harvard.HARVARD.EDU
UUCP: wanginst!ulowell!grinstein Dr. Georges Grinstein
ARPA: grinstein@ulowell.CSNET University of Lowell
VOX: +1 617 452 5000 x2681 Lowell MA 01854 USA
∂28-Dec-86 0917 UEJIOWH%CADVAX.decnet@ge-crd.arpa cl-window mailing list
Received: from GE-CRD.ARPA by SAIL.STANFORD.EDU with TCP; 28 Dec 86 09:17:00 PST
Date: 28 Dec 86 12:16 EST
From: UEJIOWH%CADVAX.decnet@ge-crd.arpa
Subject: cl-window mailing list
To: CL-WINDOWS@SAIL.STANFORD.EDU
Please add me to the cl-window mailing list
thanks,
wayne uejio
ge cr&d
bldg 37/rm 523
one river road
schenectady, ny 12345
518-387-6770
∂29-Dec-86 0634 PB80@A.CS.CMU.EDU Add to mailing list please
Received: from A.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86 06:33:57 PST
Date: Mon, 29 Dec 86 09:38 EST
From: Paul.Birkel@A.CS.CMU.EDU
To: cl-windows@SU-AI.ARPA
Subject: Add to mailing list please
Message-Id: <29Dec86.093851.PB80@A.CS.CMU.EDU>
Please add my name/address to the cl-windows mailing list.
Thank you.
Paul Birkel
pab@K.CS.CMU.EDU
∂29-Dec-86 0839 spe@cad.cs.cmu.edu Please add me
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86 08:39:15 PST
Date: 29 Dec 1986 11:37-EST
From: Sean.Engelson@cad.cs.cmu.edu
To: cl-windows@sail.stanford.edu
Subject: Please add me
Message-Id: <536258226/spe@cad.cs.cmu.edu>
Please add me to the Common Lisp Windows mailing group.
Thanks,
-Sean-
spe@cad.cs.cmu.edu
∂29-Dec-86 0946 @KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU X in lisp
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86 09:41:46 PST
Received: by ATHENA (5.45/4.7)
id AA09426; Mon, 29 Dec 86 10:39:54 EST
Date: Mon, 29 Dec 86 10:40 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X in lisp
To: elis03@sravc.sra.junet, xpert@ATHENA.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8612250007.AA05683@vc.sra.junet>
Message-Id: <861229104019.5.RWS@KILLINGTON.LCS.MIT.EDU>
I am the guilty party claiming to do a lisp implementation of X.
I cannot guarantee when it will be done. My current expectation
is to have V11 server implementations for both 3600s and Explorers.
I have informal agreements with people at both Symbolics and TI
for them to provide some of the necessary code. The implementation
will be in CL, but using extended facilities (e.g., LOOP). The
level of dependence on Flavors has not yet been determined.
The expected form of the implementation is a multi-process server
(one process per client connection, plus a few others). The
"screen" will be a vanilla window in the native window system;
that is, this will be a window system within a window system,
a "virtual console" approach.
I also hope to have a V11 client end implemented on both systems,
but in a quite different form than most other people seem to
be hacking. The idea is to implement a flavor obeying the
screen protocol of the native window system. In this way,
applications written to the native window system can run
transparently across the net. I already have a V10 implementation
of this mostly running on 3600s. This also follows the
virtual console model; what pops up on the remote screen is
a single X window, inside of which is a complete lispm window
system.
∂29-Dec-86 1129 RICHER@SUMEX-AIM.STANFORD.EDU Re: CL-WINDOWS mailing list
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86 11:29:08 PST
Date: Mon 29 Dec 86 11:28:50-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: CL-WINDOWS mailing list
To: commonloops.pa@XEROX.COM, common-lisp@SAIL.STANFORD.EDU,
xpert@ATHENA.MIT.EDU, news-makers@BRILLIG.UMD.EDU,
RICHER@SUMEX-AIM.STANFORD.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12265972863.15.RICHER@SUMEX-AIM.STANFORD.EDU>
Message-ID: <12266716971.39.RICHER@SUMEX-AIM.STANFORD.EDU>
I apologize to people on cl-windows for saying that you get on the list
by mailing to CL-WINDOWS@SAIL.STANFORD.EDU .... I meant to type
CL-WINDOWS-REQUEST@..... As many of you know adding -REQUEST is a convention
for mailing adminstrative requests such as getting added to a list
(so everyone doesn't have to see those messages). Sorry. This proves I
am only human afterall,
Mark
-------
∂30-Dec-86 0719 pyramid!pyramid.UUCP!bein@hplabs.HP.COM mailing list request..
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 30 Dec 86 07:17:49 PST
Received: by hplabs.HP.COM ; Mon, 29 Dec 86 02:44:33 pst
Received: by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86)
id AA28898; Mon, 29 Dec 86 02:03:45 PST
Date: 29 Dec 1986 01:58-PST
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: mailing list request..
To: hplabs!cl-windows@sail.stanford.edu@hplabs.HP.COM
Message-Id: <536234323/bein@pyramid>
Please add me to the list.
Thanks in advance.
--David
∂30-Dec-86 1028 rw@cad.cs.cmu.edu mailing list
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Dec 86 10:25:40 PST
Date: 30 Dec 1986 13:25-EST
From: Rob.Woodbury@cad.cs.cmu.edu
To: cl-windows@sail.stanford.edu
Subject: mailing list
Message-Id: <536351112/rw@cad.cs.cmu.edu>
Please put me on the windows mailing list.
-rob woodbury-
∂30-Dec-86 1312 ekberg%home%ti-csl.csnet@RELAY.CS.NET CL-WINDOWS request
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 30 Dec 86 13:12:44 PST
Received: from ti-csl by csnet-relay.csnet id ac00367; 30 Dec 86 16:06 EST
Received: from (home.ARPA) by tilde id AA05445; Tue, 30 Dec 86 13:10:45 cst
Received: by id AA05911; Tue, 30 Dec 86 13:11:10 cst
Date: Tue, 30 Dec 86 13:11:10 cst
From: Tom Ekberg <ekberg%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8612301911.AA05911@>
To: cl-windows@SU-AI.ARPA
Subject: CL-WINDOWS request
Please add ekberg@ti-csl to the CL-WINDOWS mailing list.
-- tom (aisle C-7)
∂05-Jan-87 0153 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET CL-WINDOWS
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Jan 87 01:53:24 PST
Received: from utokyo-relay by csnet-relay.csnet id ab00650; 5 Jan 87 4:44 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA01237; Mon, 5 Jan 87 17:19:23+0900
Received: by nttlab.ntt.junet (4.12/5.0N) with TCP; Mon, 5 Jan 87 15:26:23 jst
Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet)
id AA02230; Mon, 5 Jan 87 13:31:10 jst
Received: by kurims.kurims.kyoto-u.junet (2.0/6.2Junet)
id AA00482; Mon, 5 Jan 87 13:21:25+0900
Date: Mon, 5 Jan 87 13:21:25+0900
From: Taiichi Yuasa <yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <yuasa@kurims.kurims.kyoto-u.junet>
Message-Id: <8701050421.AA00482@kurims.kurims.kyoto-u.junet>
To: cl-windows%sail.stanford.edu%u-tokyo.junet@RELAY.CS.NET
Subject: CL-WINDOWS
Please add my name on the CL-WINDOWS mailing list. Thanks.
Taiichi Yuasa
Research Institute for Mathemetical Sciences
Kyoto University, Kyoto 606, Japan
tel: Japan 075-751-2111 ext 7238 or 7209
∂05-Jan-87 0328 mcvax!inria!devin@seismo.CSS.GOV mailing list
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 5 Jan 87 03:27:34 PST
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA26645; Mon, 5 Jan 87 06:27:31 EST
Received: by mcvax.cwi.nl; Mon, 5 Jan 87 10:10:25 +0100 (MET)
Received: by inria.UUCP; Mon, 5 Jan 87 09:19:09 -0100 (MET)
Received: by inria.UUCP; Mon, 5 Jan 87 09:19:02 -0100 (MET)
Date: Mon, 5 Jan 87 09:19:02 -0100
From: mcvax!inria!devin@seismo.CSS.GOV (Matthieu Devin)
Message-Id: <8701050819.AA02962@inria.UUCP>
To: cl-windows@sail.stanford.edu
Subject: mailing list
Would you mind adding me to the cl-windows mailing list?
best regards
Matthieu Devin mcvax!inria!devin
∂06-Jan-87 1246 RICHER@SUMEX-AIM.STANFORD.EDU discussion items
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 12:45:57 PST
Date: Tue 6 Jan 87 12:46:26-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: discussion items
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12268828250.51.RICHER@SUMEX-AIM.STANFORD.EDU>
Because I am the instigator that is trying to get this list going
again, I feel I should make some effort to start some discussion. But
it really depends on everyone to keep things going. Please comment,
disagree, or raise completely different issues. I know many of you
have more to contribute than I do so please do.
I think there are at least two broad categories of messages
appropriate for the lisp: one is to discuss the standardization of
window systems in Commonlisp, the other to disseminate or obtain
information (I have a --- that does ---; Has anyone done ---? There
is a [paper, conference, workshop, etc.] that might be of interest.)
I have a few comments that are a "reaction" to what I read in the
cl-windows archives.Those messages are 1-2 years old so it's not
surprising that they are dated now.
(1) There was some discussion about whether to use objects for a
window standard. The issue was resolved then in favor of NO objects
because an object standard did not exist. Now there is lots of hope
that some variant of Commonloops will be accepted as a Commonlisp
standard this year. So the issue cannot be dismissed so easily now.
I'd like to hear your opinions on this. One thing to consider though
is whether or not a standard could satisfy both camps. Given that
Commonloops uses function-calling and lisp syntax would both camps be
satisfied if the standard included a set of operators and accessfns
that could be implemented with either standard functional programming
or with object-oriented programming?
Beyond a base level standard there is the need for toolkits.
Should they be done with objects? A lot of folks find that very
attractive.
(2) Earlier discussions on this list seemed to feel that a CL window
standard must support all kinds of terminals including CRTs or worse.
Personally, I think it would make things a lot simpler to concentrate
on bitmap displays and not worry about what would happen on CRTs. Only
in those cases where it really makes sense to add something t for
CRTs, etc. should this be a concern. Otherwise, I think that there
will be too much compromise, too much complexity, or time taken to
agree on anything.
I also feel that you should design different interfaces if you
expect the program to run on different kinds of displays. I don't
think that you will get the optimal interface for either a bitmap
display or a CRT if you write one piece of code for both. Therefore, I
don't see a big win in having all operations do something "reasonable"
on all displays even if possible.
;(3) There was some discussion as to whether there really should be a
separate group for a graphics standard. I think the emergence of
network-based window systems such as X and NeWS suggest that there is
a need to deal with both somewhat simulataneously. If you look at X
then you see the graphics stuff must be part of the protocol or there
must be a good way to add extensions (e.g., for 3-d graphics which are
not included in X at present). With NeWS you see that the graphics
primitives need be part of Postscript. So I think the coupling must be
tighter than some may have suggested.
(4) Finally, the emergence of X and NeWS adds a completely new
dimension to CL-WINDOWS discussions. Now we are in the position of
talking about adopting other standards and agreeing on a graceful
integration with CL that will serve people's needs for a long time.
IN the short run I don't think that any one standard (i.e., X or
NeWS) can be chosen as the one for the Commonlisp language. This
raises two sets of issues:
-Can we at least agree on standard Lisp/[X, NeWS] interfaces? Is there
a level above the low-level primitives that can be standardized so
that it doesn't matter to the application programmer whether X, NeWS,
or whatever is being used? And you can really run programs on
different systems?
-Is there a set of really low-level primitives that would allow one to
efficiently implement X, NeWS, or some future window system? And are
we ready to do this?
With regard to standarding Lisp/[X,NeWS] interfaces:
It seems that there are several routes to go. On UNIX workstations
people are using the X or NeWS server that is written in C and
communicating with the server process. However, in some cases people
are using foreign function call mechanisms (which I assume are
non-standard) to define lisp functions equivalent to some existing X
function written in C. Other people are using unix pipes. On lisp
machines people are taking the approach of writing the server in Lisp.
I think we have to allow for various implementation approaches.
However, I think we want to make sure that the application programmer
does NOT have to know which implementation approach has been taken,
and furthermore code is fully compatible across hardware systems.
Otherwise, what's the point of pretending you have a standard.
Regardless of what happens in the future I think there will be X
servers available (and usually supported) on lots of hardware
configurations. Anyhow that seems to be the trend now. If NeWS catches
on then a similar thing may happen. I feel confident I will soon find
Commonlisp and X on most hardware systems, but will my Lisp
window/graphics stuff work without modification (assuming display
capabilities are similar, i.e., Vanilla X let's say) concerns me.
Mark
-------
∂06-Jan-87 1437 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU toolkits
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 14:37:08 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 6 Jan 87 17:39-EST
Date: Tue, 6 Jan 87 17:38 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: toolkits
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12268828250.51.RICHER@SUMEX-AIM.STANFORD.EDU>
Message-ID: <870106173842.4.RWS@KILLINGTON.LCS.MIT.EDU>
For what it's worth, a toolbox/toolkit proposal for X
(mostly for C) has recently been floated by DEC/HP/MIT.
Copy can be obtained via anonymous FTP to zap.mit.edu
(18.72.0.126) as /pub/proposal.out (file output) or
/pub/proposal.ps (postscript). Might be useful for
people to evaluate its overall structure in relation
to lisp, and I'm sure the people involved would be
interested in any comments.
∂07-Jan-87 1822 sdcrdcf!stephen@LOCUS.UCLA.EDU request
Received: from LOCUS.UCLA.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 87 18:22:15 PST
From: sdcrdcf!stephen@LOCUS.UCLA.EDU
Received: by sdc.uucp (4.12/sdcrdcf)
id AA00697; Wed, 7 Jan 87 16:40:28 pst
Message-Id: <8701080040.AA00697@sdc.uucp>
Received: from BIRDY by sdcrdcf with PUP; Wed, 7 Jan 87 16:40 PST
Date: 7 Jan 87 16:40 PST (Wednesday)
Subject: request
To: cl-windows%sail.stanford.edu
Cc:
please include me on the Commonlisp window system list.
stephen russell
sdcrdcf!stephen@locus.ucla.edu
∂18-Jan-87 1653 MMcM@STONY-BROOK.SCRC.Symbolics.COM discussion items
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Jan 87 16:49:27 PST
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 46021; Sun 18-Jan-87 19:37:53 EST
Date: Sun, 18 Jan 87 19:35 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: discussion items
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12268828250.51.RICHER@SUMEX-AIM.STANFORD.EDU>
Message-ID: <870118193506.4.MMCM@OWL.SCRC.Symbolics.COM>
I find it better to think of X Windows as a virtual console specification,
rather than a window system specification. In the first place, window
systems often deal with issues of window management, which are expressively
a client of X. In the second place, I think that the concepts presented by
the low-levels of X are really not those that an application programmer of
an advanced LISP system should have to deal with when programming the
window system. For instance, the methods of implementing higher level
interfaces such as scrolling viewports or asymmetrical program controlled
out of band information (like borders and labels) require the interposition
of more than one X window for what is naturally a single object to the
application programmer.
A fortiori, NewS is a graphical imaging specification. I do not expect
that given the choice, programmers of LISP systems would program directly
in the PostScript stack language.
I see no reason not to move forward toward adopting X, for instance, as the
standard, or a standard, at the right level of modularity. I sincerely
hope that programs that are written entirely in the standard language that
we produce are not fettered by having only this level. That is to say, I
hope that we can have a window system standard that is higher level than
either X or NewS.
I would not propose that this time that we attempt to standardize all the
way to the User Interface Management System level. But we can hope that
such systems as would be provided by different vendors and as part of
different libraries would themselves be written using the standard. This
would greatly increase the likelihood that they would be portable, whenever
their supplier chose to unbundle them.
I must agree that it is only natural to design the window system standard
with the emerging object orientated programming standard in mind. I would
go even further and say that it should be designed around an extension of
an integration of the existing output stream primitives with such a class
standard. We should recognize the overlap and interleaving of character
and graphical I/O in the window objects provided by the standard. Note
that I am not at this time proposing equality of stream objects and
windows.
As to the relationship between this effort and that of graphics, the
situation is pretty complicated. First off, it's obvious that the
implementation of any window system requires certain very-low-level
interfaces to hardware drivers and such for going the actual bit shuffling
that it requires. Sometimes that's known as graphics. Second, there are
those graphical operations that one performs in a window, such as drawing
lines and so on. These must be recognized by the virtual console and
imaging specifications, so there must be a way through the window system to
them. And finally, there is the very high level graphics operations that
truly graphically oriented programs, such as animation or design systems,
deal in.
I have found a data-oriented set of generic procedures to be a pretty
easily managed interface to that middle level of graphics that the window
system standard should deal with. By this I mean not a purely procedural
interface, such as PostScript provides, in as much as that locks out
low-level assistance for high-level operations, to which generic functions
are otherwise ideally suited. Nor a set of actual data entities directly
modelling the graphical output. Of course, these are invaluable when one
wishes to move past just output and deal with geometrical constraint
systems. But we are not in my opinion ready for a standardization here.
And in any case, this is the part of the system that I feel is outside the
province of window system standardization. What I am talking about, then,
is a set of functions for drawing primitive graphical output, such as
polygons, circles, lines and so on. Plus special forms for interacting
with the dynamic aspects of graphical state, such as scaling or line
thickness, in a LISP-like way. I'm sure it's obvious that either X or NewS
is well suited to the implementation of such a standard set.
To proceed, I think we should attempt to itemize those objects and concepts
with which we do expect the application programmer who is well treated by
his or her LISP system to be dealing.
∂18-Jan-87 1726 STEINBERG@RED.RUTGERS.EDU Access to Sun windows from CL
Received: from RED.RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 18 Jan 87 17:25:53 PST
Date: 18 Jan 87 20:26:04 EST
From: Louis Steinberg <STEINBERG@RED.RUTGERS.EDU>
Subject: Access to Sun windows from CL
To: cl-windows@SAIL.STANFORD.EDU
cc: steinberg@RED.RUTGERS.EDU
Message-ID: <12272024883.36.STEINBERG@RED.RUTGERS.EDU>
Rather than discussing standards and future directions, this message
is a request for pointers to code available here-and-now. I teach a
course on AI Programming. We use Franz Common Lisp on Suns (running
release 3.2 of the Sun Unix). I would like to have my students write
code that can create and access windows and the mouse. (Cursor
positioning is needed but not graphics.) It would be nice if this
code worked with the SunTools package, but not necessary.
Does anyone have any pointers to packages that might help?
Thank you.
Louis Steinberg
Department of Computer Science
Rutgers University
-------
∂18-Jan-87 1753 dcmartin@ingres.berkeley.edu Re: Access to Sun windows from CL
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 18 Jan 87 17:52:53 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
id AA18611; Sun, 18 Jan 87 17:52:07 PST
Message-Id: <8701190152.AA18611@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Louis Steinberg <STEINBERG@red.rutgers.edu>
Cc: cl-windows@sail.stanford.edu
Precedence: priority-mail
In-Reply-To: Your message of 18 Jan 87 20:26:04 EST
Subject: Re: Access to Sun windows from CL
Date: 18 Jan 87 17:52:05 PST (Sun)
Sender: dcmartin@ingres.berkeley.edu
I am building such a package and have most of the X functionality available
from ExCL. This package is also interfaced to Portable CommonLoops which
supplies the object oriented extensions. If you would like the code, it
is available by anonymous ftp from ingres.berkeley.edu in ~ftp/pub/bool.
It doesn't work completely, but it does provide most of the functionality.
Franz Inc may be able to provide you with more information about the
availability of other windowing systems for ExCL.
Franz Incorporated
1141 Harbor Bay Parkway
Alameda, CA 94501
(415) 769-5656
..!ucbvax!franz!info or info%franz@berkeley.edu
dcm
∂20-Jan-87 1200 RAM@C.CS.CMU.EDU X interface standard
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Jan 87 09:59:24 PST
Received: ID <RAM@C.CS.CMU.EDU>; Tue 20 Jan 87 12:55:51-EST
Date: Tue, 20 Jan 1987 12:55 EST
Message-ID: <RAM.12272467201.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: cl-windows@SAIL.STANFORD.EDU
Subject: X interface standard
I think that coming up with an X interface standard is a
worthwhile near-term goal for this group. The main reason I think
that we should concentrate on an X interface is that I can conceive of
something coming out of it. The reason is that two fundamental things
needed for convergence on a stardard are present in the case of X:
1] A baseline proposal that establishes a common ground for
discussion and resolves many of the necessary arbitrary decisions
in a necessarily arbitrary way.
2] A group of people who care enough about the result to provide the
necessary manpower and feedback.
It seems that X has become something of a de-facto stardard. Here
at CMU, we are planning to use X as the standard basis for our user
environment and user interface work. We are at this moment working on
coming up with a basic interface to X. Other messages indicate that
other groups have already done this. I get the impression that these
interfaces are mostly "quick and dirty"; what we need to do is get
some of the people who have been involved in these efforts to think
about proposals for interfaces that are reasonable clean and portable,
yet stay close enough to X so that we don't get lost.
I suggest these priorities in an X interface design:
1] Portability and consistency with general Common Lisp design
philosophy.
2] Access to full X functionality.
3] Generalization of design to admit use of other window systems and
to allow for future extensions.
Initially, I was opposed to the idea of using Common Loops in the
X interface, but I now see some major advantages.
Pro:
1] Objects provide a clean solution to the input event
demultiplexing/dispatching problem. Non-trivial applications need
to be able to respond to various kinds of things happening to any
of a number of screen objects. The best solution to this problem
seems to be to use an event driven, object oriented structure for
the application. Although the doesn't require the use of an
object oriented programming system per-se, it makes sense to use
the one that we have already standardized on.
2] Using an object oriented approach provides an easy path toward
more ambitious window management standards.
Con:
1] Since an object oriented approach would resemble hairy proposals
that "solve all the world's problems", it might be more difficult
to converge on a standard, since the crinophiles would complain
that it impeded the ultimate hairy apothesis.
2] There is an efficiency penalty. Perhaps we could reduce this
problem by making the basic output operations non-generic.
We might also consider making the set of non-generic operations
large enough so that an interface could support everything but
event-driven input without having an object system at all.
Whether we use objects or not, we have a significant task in coming up
with lispy interfaces to the basic X operations. I encourage people
to send proposals discussing how these interfaces are to be done.
Rather than simply describing the interface to each routine, a
proposal should:
-- Describe general rules for generating the interfaces to "easy"
routines.
-- Describe specific solutions to problems with particular routines,
together with the rationale for the proposed solution. This will
mostly involve the few routines that accept or return complex
data structures.
Well, now you all have your assignments. Go to it, but remember that
points will be taken off for exhibiting bad attitude by disagreeing
with me. :-)
Rob
∂21-Jan-87 1328 RICHER@SUMEX-AIM.STANFORD.EDU X/Lisp from ailist
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Jan 87 13:28:49 PST
Date: Wed 21 Jan 87 13:11:59-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: X/Lisp from ailist
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12272765061.66.RICHER@SUMEX-AIM.STANFORD.EDU>
The following was extracted from ailist digest:
Date: Thu, 15 Jan 87 09:58:16 PST
From: TAYLOR%PLU@ames-io.ARPA
Subject: Request for Info on Lisp Machine Window Systems
We have been developing a user interface for a planning/scheduling
application on the Symbolics, using Version 6.1 windows and flavors.
For future long term development of the user interface, we are
considering a possible change of the window system, before converting
to Genera 7.0 Dynamic windows and Presentation types. We have heard
mention of XWINDOWS and are interested in knowing about it and other
"generic" window systems and the trade-offs between specialized
features and portability.
Issues we are looking at:
o will window system be compatible with a future Common
lisp window standard
o will window system be portable between lisp machines and
AI work stations, e.g. Symbolics, TI, LMI, Xerox, Sun, ..
o how much conversion will be required to go from current
implementation, now running under Genera 7.0, to a new
window system
o what are advantages/disadvantages of potential window
systems as far as ease of implementation, facilities
available to present information to user, use of object
oriented techniques, etc
ow availability of potential window systems on the Symbolics
Opinions and recommendations are solicited from Lisp machine users
as to their experience and preferences. Please respond by e-mail.
I will summarize for this bboard if requested and sufficient responses
are received.
Thanks - Will
Will Taylor - Sterling Software, MS 244-7,
NASA-Ames Research Center, Moffett Field, CA 94035
arpanet: taylor%plu@ames-io.ARPA
uusenet: ..!ames!pluto.decnet!taylor
phone : (415)694-6525
------------------------------
-------
∂21-Jan-87 1419 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU random thoughts
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Jan 87 14:18:48 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 Jan 87 17:15-EST
Date: Wed, 21 Jan 87 17:17 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: random thoughts
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870121171715.3.RWS@KILLINGTON.LCS.MIT.EDU>
A significant characteristic of the TI and Symbolics window systems is
that output (and most window management functions) are synchronous; if
you call DRAW-LINE, then when the function returns, you know the line
has been drawn. Thus, you needn't worry about forcing output when you
go off to do something else (like wait for input).
A significant characteristic of the X protocol (and also NeWS) is that
output is inherently asynchronous, and that it is important to buffer
multiple requests into a single IPC segment. Thus, someone or something
has to be responsible for forcing output.
I believe buffering and asynchrony must be explicit at the application
level. The application must be responsible for forcing output.
In the TI and Symbolics worlds, the view for the most part is invoking
functions on a window object, or on a stream connected to a window
object. With the X protocol, one should think of implementing using a
single IPC channel between an address space and an X server, not an IPC
channel per window. How should this be abstracted? Is there a virtual
channel per lisp process [we ought to be thinking about multi
process(or) worlds] such that forcing one isn't abstractly defined to
force the others, or if there is a single channel, is the
synchronization implicit or explicit? Similar synchronization questions
arise at every object abstraction level.
Are operations performed on windows (or streams), or on consoles (with a
window passed as an argument), or on graphics contexts (as they exist in
X, with a window passed as an argument)? If performed on other than a
console, is "force output" abstracted to per window or context, or is it
simply per console? Should a graphics operation be defined by a
(graphics context, window) pair as in X, or is one element of the pair
embedded inside the other? Is the graphics context explicit as object
state, or is it embedded in control context (e.g., with-character-style,
with-line-width)?
∂21-Jan-87 1458 @KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU X Version 11 protocol document
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Jan 87 14:54:25 PST
Received: by ATHENA (5.45/4.7)
id AA12834; Wed, 21 Jan 87 14:56:52 EST
Date: Wed, 21 Jan 87 14:58 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X Version 11 protocol document
To: xpert@ATHENA.MIT.EDU, xport@ATHENA.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
Message-Id: <870121145815.4.RWS@KILLINGTON.LCS.MIT.EDU>
The "nearly final" document describing the Version 11 protocol of the
X Window System is now available via anonymous ftp (i.e., use login
"anonymous", any password) to zap.mit.edu (18.72.0.126) as the text file
/pub/x11.spec
The file is 171510 bytes long. Those without ftp access can send mail
to me requesting a personal copy, and I will respond as time permits.
I cannot reasonably cope with requests for postal service.
Note that this document (still) does not give precise formats or bit
encodings. Such information of course exists, and will be published
eventually as a separate document.
∂22-Jan-87 1431 RAM@C.CS.CMU.EDU random thoughts
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jan 87 12:00:55 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 22 Jan 87 15:00:24-EST
Date: Thu, 22 Jan 1987 15:00 EST
Message-ID: <RAM.12273014149.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: random thoughts
In-reply-to: Msg of 21 Jan 1987 17:17-EST from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Date: Wednesday, 21 January 1987 17:17-EST
From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
To: cl-windows at SAIL.STANFORD.EDU
Re: random thoughts
A significant characteristic of the X protocol (and also NeWS) is
that output is inherently asynchronous, and that it is important
to buffer multiple requests into a single IPC segment. [...] I
believe buffering and asynchrony must be explicit at the
application level. The application must be responsible for
forcing output.
[...] With the X protocol, one should think of implementing using
a single IPC channel between an address space and an X server, not
an IPC channel per window. [...]
It isn't clear to me that this follows. I think that the single IPC
connection can be regarded as an unimportant quirk of the current X
implementation. I would favor an implementation which admits the
possibility of separate buffering for each object, and then provide
operations for flushing large sets of buffers, such as all buffers or
all buffers for a subtree of the window hierarchy.
There should also be some automatic buffer flushing, such as flushing
buffers before going into an input wait. This will eliminate most of
the need for explicit buffer flushing.
A per-object connection implies that there is no guaranteed ordering
of operations that are done on distinct objects unless explicit
synchronization is done.
If we allow per-object communication channels, then it is potentially
expensive to synchronize with the server and verify that preceding
operations have actually been done, since it could require doing a
handshake on many connections. I think that requiring syncronization
is sufficiently rare that it is reasonable to require explicit
synchronization on each object.
Allowing a per-object communication channel is basically a worst case;
code which assumes a per-object channel will work on implementations
with fewer channels, but not the other way around.
I have extensively used the Sapphire window system on the CMU Spice
system. Sapphire uses the Accent IPC to implement a partially
asynchronous RPC system with an implicit per-object communication
channel. Since the object knows everything necessary for
communication with the server, the application can operate on windows
on different machines without knowing it.
[...] Are operations performed on windows (or streams), or on
consoles (with a window passed as an argument), or on graphics
contexts (as they exist in X, with a window passed as an
argument)? [...] Should a graphics operation be defined by a
(graphics context, window) pair as in X, or is one element of the
pair embedded inside the other? Is the graphics context explicit
as object state, or is it embedded in control context (e.g.,
with-character-style, with-line-width)?
I don't know enough about how X graphic contexts are supposed to be
used to be sure, but I think the correct solution is to embed the
graphics context within the window object. We then need some sort of
rule for choosing the correct graphics context when performing a
multi-window operation. I think that the correct solution is to use
the context for the destination.
Basically, I think the window is the "real object" and should somehow
implicitly provide any other necessary context such as the server
connection or graphics context. The main reason I believe this is
that it seems much more useful to think of input events as happening
on windows, rather than happening on some less specific object, with
the window as extra information.
Rob
∂22-Jan-87 1530 MMcM@STONY-BROOK.SCRC.Symbolics.COM random thoughts
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Jan 87 15:29:02 PST
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49563; Thu 22-Jan-87 18:20:29 EST
Date: Thu, 22 Jan 87 18:17 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: random thoughts
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870121171715.3.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870122181745.2.MMCM@OWL.SCRC.Symbolics.COM>
I agree that the virtual console and probably window system layers must
expect asynchrony and deal with forcing output. I would contend that a
good UIMS wouldn't require an application to deal with this. I guess
that means my UIMS is an application in your domain. Fine.
A multiplexed IPC channels to a server is certainly a good
implementation. However, I feel that application programmers should act
as if there were separate channels to the server for each window. They
should not be burdened with worrying about the multiplexing. This might
mean that a force from any window forces output to all windows, which I
don't see as a priori wrong. Or it might mean that there is an
intermediate buffering layer between window output and the network
channel, such that any subset can be forced. I do not feel that
per process is the right level of abstraction. Processes basically
should be separate from collections of windows that make up an activity.
I believe all operations should be performed on streams. A window is
represented by a stream. A pair of graphics context and window is also
a stream. It is my experience that the problems with bundling together
such behaviors arise from a system's reluctance to let you create
children streams, rather than a fundamental good reason to deal with
separate objects. I will remind everyone that classes make it easy to
get this combining and keep good modularity.
I have found that having the graphics context as object state is a good
implementation technique, but that dynamic extent is almost always what
an application programmer wants. I might point out that your
with-line-width can be implemented via setf and unwind-protect in those
environments in which multiprocess access to the stream is not an issue.
I have also found it enormously convenient to have keyword arguments to
all output functions that provide single operation access to this
dynamic binding. For example, draw-ellipse takes a rotation argument
which works by executing the meat of draw-ellipse inside a with-rotation.
∂23-Jan-87 1319 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU random thoughts
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jan 87 13:18:06 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 23 Jan 87 16:17-EST
Date: Fri, 23 Jan 87 16:18 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: random thoughts
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12273014149.BABYL@C.CS.CMU.EDU>
Message-ID: <870123161813.9.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <RAM.12273014149.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
I think that the single IPC
connection can be regarded as an unimportant quirk of the current X
implementation. I would favor an implementation which admits the
possibility of separate buffering for each object, and then provide
operations for flushing large sets of buffers, such as all buffers or
all buffers for a subtree of the window hierarchy.
Viewing each window as a separate sequencing entity only works when you
use windows as large-grain objects. If you start to use lots of windows
for lots of little things (e.g., menu items, button boxes), with
abstraction levels completely hiding the number of windows involved, as
is often done in X, then the ability to control the order of execution
across an arbitrary set of windows becomes quite important. It is not
sufficient to "flush large sets of buffers", the total order is
significant.
There should also be some automatic buffer flushing, such as flushing
buffers before going into an input wait. This will eliminate most of
the need for explicit buffer flushing.
Depends on your system structure. If you look at the current Symbolics
world, you wait on an "io-buffer", which has no explicit back-link to
any window/screen/console (indeed, multiple windows can share a single
io-buffer). This is indeed one of the difficulties I ran into in trying
to slip X in underneath the current Symbolics interface.
If we allow per-object communication channels, then it is potentially
expensive to synchronize with the server and verify that preceding
operations have actually been done, since it could require doing a
handshake on many connections.
Absolutely true.
I think that requiring syncronization
is sufficiently rare that it is reasonable to require explicit
synchronization on each object.
Absolutely false. I think there is a large body of X code that represents
a strong counter-argument.
I don't know enough about how X graphic contexts are supposed to be
used to be sure, but I think the correct solution is to embed the
graphics context within the window object.
If you really mean "embed the window and graphics context in a stream",
I might agree with you. Certainly, two distinct processes ought to be
able to manipulate the same window with distinct graphics contexts.
∂23-Jan-87 1423 @ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU random thoughts
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jan 87 14:20:57 PST
Received: from KILLINGTON.LCS.MIT.EDU (KILLINGTON.LCS.MIT.EDU) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 26870; 23 Jan 87 17:12:50 EST
Date: Fri, 23 Jan 87 17:12 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: random thoughts
To: MMcM@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870122181745.2.MMCM@OWL.SCRC.Symbolics.COM>
Message-ID: <870123171256.1.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 22 Jan 87 18:17 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Processes basically should be separate from collections of windows
that make up an activity.
I agree that an activity is not defined by a collection of windows, but
I believe it is extremely desirable to hold that, for a single execution
thread, all requests issued to a single console are executed in the
order the were issued. Interleaving among threads should certainly be
undefined except possibly via explicit synchronization; at that point
the notion of an activity and sequencing of requests from a single
activity might be useful.
I have found that having the graphics context as object state is a good
implementation technique, but that dynamic extent is almost always what
an application programmer wants. I might point out that your
with-line-width can be implemented via setf and unwind-protect in those
environments in which multiprocess access to the stream is not an issue.
Dynamic extent is a nice idea, but (I would claim) one has to be very
careful about performance penalties, and the same holds true for the
meaning of context as object state. If you look at high-performance
display hardware being built today, much of the graphics state is stored
in hardware. By graphics state I mean such things as the line-width,
source pixel, tile pattern, font, clipping region, etc. The more "all
singing, all dancing" the hardware, the more state stored. Typically
the hardware will support some fixed number of context blocks that you
can switch between rapidly, because reloading all the state on every
operation would be enormously expensive. In fact, even CHECKing if the
desired state matches the current state would be very expensive, so it
is imperative that there be some way to check that fast. The
manifestation of this in X is that there is an explicit resource, called
a graphics context, with an independent identity. This makes checking
whether the state is loaded trivial. So, point number one is that the
graphics context must be more than the sum of its parts. Now, one might
be tempted to associate the state with the window itself, or with a
stream to the window; both approaches have real limitations. If you
associate it with the window, then independent processes can't
manipulate the window with independent graphics state. If you associate
the state with a stream to the window, then you can't apply a single
graphics context to an arbitrary number of windows. If you view windows
as a cheap resource to be used in abundance, as is done in X, then the
ability to apply a graphics context uniformly to a collection of windows
is important. Note that for a given graphics context, switching windows
is essentially a matter of switching the clipping region, just one
component of the state, and one for which there is a quick check for
equality (namely, window identity). If there is no independent identity
for the graphics context, then switching windows with equivalent
embedded state will require an expensive check.
Summing, I believe the model of a stream containing both a window and a
graphics context, with the ability for streams to share both windows and
graphics contexts, is important. This means window and context are
instance variables of the stream, not component objects, and this has
implications for determining "who is in control". It may also be
important to be able to change both the window and the graphics context
of a stream. I believe dynamic extent for graphics state is important,
but I also believe that object state is vital for high performance.
I have also found it enormously convenient to have keyword arguments to
all output functions that provide single operation access to this
dynamic binding. For example, draw-ellipse takes a rotation argument
which works by executing the meat of draw-ellipse inside a with-rotation.
For absolute performance there should be a direct interface that simply
uses the stream state. There should be a "reduced operator" interface
that allows keyword override for at least the graphics state more
commonly changed. Having only a full-blown keyword interface would seem
to me to force to much of a performance penalty. Also, if one wants the
graphics context to be extensible (e.g., adding a coordinate transform
if one isn't initially provided, or adding 3-D state), one would prefer
an interface that doesn't necessarily require explicit code modification
for each extension. In the case of keywords, this would seem to mean
you have to define the generic function with &allow-other-keys, and it
must call on the graphics context to process the keywords.
∂25-Jan-87 0823 RAM@C.CS.CMU.EDU random thoughts
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Jan 87 08:23:02 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 25 Jan 87 11:22:59-EST
Date: Sun, 25 Jan 1987 11:22 EST
Message-ID: <RAM.12273761005.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: random thoughts
Date: Friday, 23 January 1987 16:18-EST
From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
cc: cl-windows at SAIL.STANFORD.EDU
Re: random thoughts
Message-ID: <RAM.12273014149.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
I think that the single IPC
connection can be regarded as an unimportant quirk of the current X
implementation. I would favor an implementation which admits the
possibility of separate buffering for each object, and then provide
operations for flushing large sets of buffers, such as all buffers or
all buffers for a subtree of the window hierarchy.
Viewing each window as a separate sequencing entity only works when you
use windows as large-grain objects. If you start to use lots of windows
for lots of little things (e.g., menu items, button boxes), with
abstraction levels completely hiding the number of windows involved, as
is often done in X, then the ability to control the order of execution
across an arbitrary set of windows becomes quite important.
Could you provide an example please? I'm having difficulty thinking
of any common situations where the relative sequencing of operations
on two screen objects is very important. I think that this is
actually a fairly basic property of window systems, since their entire
purpose is to prevent interactions between windows by giving them
logically distinct bits. The only examples that I can think of
involve operations on two windows with a nesting relationship. For
example, you might need to make sure that an outer window had been
resized before you resize its subwindows.
I think that requiring syncronization
is sufficiently rare that it is reasonable to require explicit
synchronization on each object.
Absolutely false. I think there is a large body of X code that represents
a strong counter-argument.
I don't think that existing X code has direct relevance to this issue
since X *does* have implicit synchronization between hierarchically
related windows. Because this synchronization is automatic, the
programmers probably have no idea of what explicit synchronization
would be necessary in a system that required it.
I don't know enough about how X graphic contexts are supposed to be
used to be sure, but I think the correct solution is to embed the
graphics context within the window object.
If you really mean "embed the window and graphics context in a stream",
I might agree with you. Certainly, two distinct processes ought to be
able to manipulate the same window with distinct graphics contexts.
No, I certainly don't mean that. First, let me say that I object to
this use of the term "stream" in this discussion. We have not yet
established that there is any relationship between the Common Lisp
stream concept and any window system proposal. I object to the role
that you seem to be assigining to streams for two reasons:
1] Many systems have highly tuned stream implementations not based
object systems that will not mesh well with an object based window
system.
2] I think that there is little gain in encorporating streams
directly into the window system, since most operations will make
no use of the stream protocol. It is obviously useful to be able
to implement a text I/O stream using a window, but I don't think
that this is a good fundamental unifying principle for a window
system. A Make-Window-Stream function would be entirely adequate.
My idea is that there is a single level in the window system, with the
default graphics context being specified by a slot in the Window
object. It seems to be that this scheme is simpler and more efficient
than having a separate "stream" object that relays the message to the
window, supplying the graphics context.
We can allow for applications that need to use multiple contexts in
the same window simultaneously by having the graphics context be an
optional, or having separate operations that accept the graphics
context. Of course, the default graphics context can also be set.
Given this level of access, you can define "stream" to do whatever you
want, and it won't bother me as long as I don't have to implement it.
Rob
∂25-Jan-87 1355 MMcM@STONY-BROOK.SCRC.Symbolics.COM random thoughts
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jan 87 13:54:51 PST
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51287; Sun 25-Jan-87 16:52:59 EST
Date: Sun, 25 Jan 87 16:54 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: random thoughts
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870123171256.1.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870125165439.1.MMCM@OWL.SCRC.Symbolics.COM>
I believe your concerns and suggestions about state based interfaces
belong in implementation notes, not in the standard.
That there need be a significant penalty for keyword arguments is at
least in part superstition. I assume that most production compilers
apply reasonable optimization for the keyword arguments to the standard
sequence functions, although no such requirement is given in the
specification, and no version of those functions that does not take
keyword arguments is provided.
Your example graphics engine is not the only possible hardware
assistance. I could well imagine a more symbolic processor in which
dynamic creation of linked state blocks on a control stack is much
faster than a full write through to a state in main memory, which might
require multi-processor synchronization, or who knows what. I see no
reason to suppose such a processor could not have a graphics engine
following the same architecture principals.
Given that we agree that dynamic binding is the right interface for
application programmers, I do not believe the specifcation should
require either shallow or deep binding implementation.
In other words, the issue is whether well tuned implementations can give
a high performance program quick access to state control without
distortion of good modularity. I contend they can.
∂27-Jan-87 0346 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU random thoughts
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Jan 87 03:45:47 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 27 Jan 87 09:45-EST
Date: Tue, 27 Jan 87 09:47 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: random thoughts
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12273761005.BABYL@C.CS.CMU.EDU>
Message-ID: <870127094700.7.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Sun, 25 Jan 1987 11:22 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Date: Friday, 23 January 1987 16:18-EST
From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
... the ability to control the order of execution
across an arbitrary set of windows becomes quite important.
Could you provide an example please? I'm having difficulty thinking
of any common situations where the relative sequencing of operations
on two screen objects is very important.
I contend that we should preserve sequentiality, and (as much as
possible) maintain the illusion of synchronicity, because it greatly
simplifies reasoning about programs and the structure of programs. A
few examples:
1. The visual appearance of display update is an important
consideration. Just to say that "the quiescent-state bits are the same"
is not sufficient to capture dynamic visual desires. Given reasonable
abstractions, the application will have relatively little knowledge of
how many and what structure of windows are used in a given composite
object, and disjoint composite objects will have little knowledge about
how they should relate to each other, making application-level
synchronization painful. The tie that binds (I claim) is the sequential
execution order of the process; things should be performed in the order
they are requested.
2. Say I want to "map all children of window W", and then immediately
draw into the children (which don't have backing stores). The map
operation is on the parent window; it is important for performance that
this not be done as separate operations on each child. Unless the map
operation actually gets executed before the graphics on the children,
some graphics will be lost.
3. If an application performs output on two windows, and also frequently
bitblts between them, the cost of round-trip synchronization for the
bitblts will be totally unacceptable.
4. Drawing "through" subwindow boundaries seems to be an (unpleasant)
reality. An example is rubber-banding a rectangular outline for placing
objects in an overlapped environment, where the objects are implemented
with (sub)windows. Again, synchronizing with all inferior windows seems
painfully complicated.
5. Let's say I want to open a font, and then use it in painting text to
a window. Fonts (I claim) should be associated with consoles, not with
individual windows. You certainly don't want to force synchronization
on all possible windows every time you create a window-independent
resource. You also certainly don't want the resource creation itself to
require a round-trip; that's the way it works in Version 10 of X, and it
was a BIG mistake, resulting in very noticeable delays and ugly
programatic interfaces to kludge around the problem. (Version 11 of X
does not require a handshake for resource creation.)
6. In general, a real window system is likely to have numerous
operations that can't be easily associated with a single window, and yet
the application will desire the ability to trivially achieve sequencing.
I don't think that existing X code has direct relevance to [per-object synchronization]
since X *does* have implicit synchronization between hierarchically
related windows. Because this synchronization is automatic, the
programmers probably have no idea of what explicit synchronization
would be necessary in a system that required it.
I claim that maintaining sequential reasoning has been extremely
beneficial in X. I also point out that in Version 10 of X, I (naively)
assumed that round-trip synchronization at resource creation wouldn't be
a problem; it turned out to be a very significant problem. As such, I
am very wary of any vague claims that synchronization won't be required
"that often".
∂27-Jan-87 0407 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU random thoughts
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Jan 87 04:04:33 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 27 Jan 87 10:04-EST
Date: Tue, 27 Jan 87 10:05 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: random thoughts
To: MMcM@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870125165439.1.MMCM@OWL.SCRC.Symbolics.COM>
Message-ID: <870127100539.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Sun, 25 Jan 87 16:54 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Your example graphics engine is not the only possible hardware
assistance. I could well imagine a more symbolic processor in which
dynamic creation of linked state blocks on a control stack is much
faster than a full write through to a state in main memory, which might
require multi-processor synchronization, or who knows what.
(Careful, or you will start to argue that stack-based languages are
inherently superior to object-based languages. :-)
I see no
reason to suppose such a processor could not have a graphics engine
following the same architecture principals.
Sure, but you seem to sidestep my point, which is that much existing
(and near future) graphics hardware works essentially as I described,
and I believe it is important to perform well on that hardware. Also,
you seem to assume in your proposed architecture that the application
process and the graphics engine are tightly-coupled in hardware, rather
than being potentially separated by a network. I claim the design
should be predicated on the assumption that a remote console will likely
be implemented as a single thread, multiplexing requests from many
applications. Assuming a multi-threaded server, much less a server that
has a thread with a mirrored dynamic context for every remote
application thread, is unrealistic.
Given that we agree that dynamic binding is the right interface for
application programmers, I do not believe the specification should
require either shallow or deep binding implementation.
I agree that dynamic binding is an important interface to support, but I
believe that there will be applications for which dynamic binding alone
is inadequate; an explicit notion of graphics state should be possible.
∂27-Jan-87 0450 Freburger.ULC@BCO-MULTICS.ARPA Mailing list
Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jan 87 04:50:02 PST
Date: Tue, 27 Jan 87 10:07 EST
From: Freburger@BCO-MULTICS.ARPA
Subject: Mailing list
To: cl-windows@SU-AI.ARPA
Message-ID: <870127150751.674800@BCO-MULTICS.ARPA>
Please add me to your mailing list. My address is:
freburger@bco-multics.arpa
Thanks.
- Karl Freburger
∂27-Jan-87 0920 Skef@think.com Window system psychomysticism
Received: from ZARATHUSTRA.THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Jan 87 09:17:19 PST
Received: from Godot.Think.COM by zarathustra.think.com; Tue, 27 Jan 87 12:17:24 EST
Received: from wenceslas by Godot.Think.COM via CHAOS; Tue, 27 Jan 87 12:17:15 EST
Date: Tue, 27 Jan 87 12:18 EST
From: Skef Wholey <Skef@think.com>
Subject: Window system psychomysticism
To: RWS@zermatt.lcs.mit.edu, RAM@c.cs.cmu.edu
Cc: cl-windows@sail.stanford.edu
In-Reply-To: <870127094700.7.RWS@KILLINGTON.LCS.MIT.EDU>
Message-Id: <870127121803.1.SKEF@WENCESLAS.THINK.COM>
Date: Tue, 27 Jan 87 09:47 EST
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
...I contend that we should preserve sequentiality, and (as much as
possible) maintain the illusion of synchronicity...
It seems to me that synchronicity lies somewhat outside the domain of
a window system, a Lisp system, or even an advanced AI system.
Synchronization, on the other hand, is another issue.
(-: Skef :-)
∂27-Jan-87 1739 RICHER@SUMEX-AIM.STANFORD.EDU Lisp interfaces to X
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Jan 87 17:39:35 PST
Date: Tue 27 Jan 87 17:38:57-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Lisp interfaces to X
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12274386526.33.RICHER@SUMEX-AIM.STANFORD.EDU>
Now that I understand some of the ways in which Commonlisp interfaces
to X can vary, I'd like to make a strong plea that "we" agree on a
standard Commonlisp interface for version 11 of X. What I think is needed is
that the vendors (HP, DEC, etc.) that have endorsed X somehow come to agreement
with each other as well as the lisp software vendors (franz, lucid, etc.),
people on the list, and the CL committee. It should be relatively easy
to standardize this. IF someone disagrees, then they should point out
the areas of interfacing with X where decisions are not arbitrary and have
interesting consequences. Admittedly, I am a (new) consumer of X so I'm
experssing what I assume is the hope of the general user community ("please
standardize"). Those of you that have built lisp interfaces to X either
by using a foreign function-call interface to X or by implementing the
server and Xlib in lisp totally should be the ones to propose a standard
interface. Any volunteers?
Mark
-------
∂28-Jan-87 0827 dcmartin@ingres.berkeley.edu Re: Lisp interfaces to X
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 08:26:48 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
id AA19091; Wed, 28 Jan 87 08:26:02 PST
Message-Id: <8701281626.AA19091@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Mark Richer <RICHER@sumex-aim.stanford.edu>
Cc: cl-windows@sail.stanford.edu
Precedence: priority-mail
In-Reply-To: Your message of Tue 27 Jan 87 17:38:57-PST
Subject: Re: Lisp interfaces to X
Date: 28 Jan 87 08:25:59 PST (Wed)
Sender: dcmartin@ingres.berkeley.edu
I agree with Mark Richter in that some sort of CL interface w/ X version 11
as the support base should be the standard of choice. Seeing how much
publicity CommonWindow's has received, and after reviewing the document, there
appears to be quite a number of things that Xv11 will provide which
CommonWindows will not exploit.
I have built a 60% complete interface between X (version 10) and Common LISP
using the foreign function system from Franz, Inc. This code has some
improvements over the standard C library (e.g. allowing non-blocking reads
from the event stream) and some extensions particular to UNIX (e.g. allowing
the programmer to get the DISPLAY environment variable). However, there are
some major problems that I have encountered in using the C libraries as the
support mechanism for my CL. Most notably the pain involved in allocating
and deallocating the necessary C data structures and maintaining these
structures in some coherent fashion.
There is also the major problem of the sheer size of CL. Since the ExCL
binary requires over 4MB of memory after my X stuff is loaded, I can only
run one application under each CL. Another member of the group has built
a portable scheduler for CL which allows "sub-processes" to run on an event
driven priority (i.e. the scheduler gets an event from the X server, starts
the appropriate sub-process, which runs until it decides to stop, then the
scheduler repeats). It would seem that some notion of context switching
still needs to be addressed as a standard extension to CL.
The method that I have used in building my X package is to provide the
same basic names as the C library functions for X. In some cases the
arguments are optionalized, or have been extended to provide more
functionality, but the basic naming scheme and calling conventions remain
pretty much the same. There is no standard for the naming or arguments for
the library functions per se, in either X version 10 or version 11, and perhaps
that is something that the people at MIT should think about. There is a
specification of that the protocol will support and what the arguments and
types are, but there is nothing in the specification (unless I totally
missed it).
Since people may be wanting to use either X or NeWS, and since the X 11
protocol seems to allow almost everything you ever wanted to do with
a window (but were afraid to ask), I propose that the basic X version 11
protocol become the base standard for CL. Then the only question to figure
out is what are the standard extensions. The "problem" of naming could be
easily rectified by simply adopting the protocol naming scheme.
Comments?
dcm
-----
David C. Martin
-----
Computer Science Division
University of California
Berkeley, CA 94720
-----
arpa: dcmartin@ingres.Berkeley.EDU
uucp: {ihnp4,decvax}!ucbvax!dcmartin
at&t: 415/642-9585 (O)
∂28-Jan-87 0902 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: Lisp interfaces to X
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 09:02:02 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 28 Jan 87 11:59-EST
Date: Wed, 28 Jan 87 12:00 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: Lisp interfaces to X
To: dcmartin@INGRES.Berkeley.EDU, RICHER@SUMEX-AIM.STANFORD.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8701281626.AA19091@ingres.Berkeley.EDU>
Message-ID: <870128120042.3.RWS@KILLINGTON.LCS.MIT.EDU>
I think a vanilla translation of the V11 C library into Lisp
is almost certainly the wrong thing. Certainly implementing
via a foreign function interface to the C library is the wrong
thing. Some attempt at making a rational OOP interface is
called for, as well as deciding things like keyword arguments
and dynamic binding models. I would agree that an X-specific
interface is a useful first step towards something more
general, and will satisfy immediate needs at numerous sites.
∂28-Jan-87 0953 dcmartin@ingres.berkeley.edu Re: Lisp interfaces to X
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 09:51:40 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
id AA19796; Wed, 28 Jan 87 09:49:02 PST
Message-Id: <8701281749.AA19796@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Cc: RICHER@sumex-aim.stanford.edu, cl-windows@sail.stanford.edu
Precedence: priority-mail
In-Reply-To: Your message of Wed, 28 Jan 87 12:00 EST
Subject: Re: Lisp interfaces to X
Date: 28 Jan 87 09:48:59 PST (Wed)
Sender: dcmartin@ingres.berkeley.edu
True, a vanilla translation would buy you nothing, but some sort of lowest
level implementation should be decided upon for the library interface. As
for an OOP system, that is what I am working on using Common LOOPS. Currently
I have about 60% of the X system OOified and am working on more as the needs
of the application people in my group increase. I don't think that an OOP
interface is necessarily the end result of any work done, since some people
will not wish to use an OO system.
I would like to know what you (specifically) and others want to see in an
initial, low level, X Common LISP library. I am not a LISPer of long standing,
so my guidelines have come from the LMI Window spec and input from people here
at Berkeley (and Franz). Currently all I am doing is a vanilla X/CL interface
with some new functions (which take keywords). Granted that the foreign
function stuff is gross and a pain to work with, but it has so far been hidden
from the application level.
Some of the questions I have are regarding things like stream based windows,
the UNIX interface (getenv, etc...) and what additional functionality a LISP
programmer wants beyond what a C programmer wants. I know that latter, but
not the former.
Thanks.
dcm
∂28-Jan-87 1242 RICHER@SUMEX-AIM.STANFORD.EDU Re: Lisp interfaces to X
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 12:41:07 PST
Date: Wed 28 Jan 87 12:40:35-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Lisp interfaces to X
To: dcmartin@INGRES.BERKELEY.EDU
cc: cl-windows@SAIL.STANFORD.EDU, RICHER@SUMEX-AIM.STANFORD.EDU
In-Reply-To: <8701281626.AA19091@ingres.Berkeley.EDU>
Message-ID: <12274594352.81.RICHER@SUMEX-AIM.STANFORD.EDU>
One thing David didn't mention in regard to a Lisp/X interface was brought
to my attention by Marty Cagan of HP. I believe he told me that there
are cases where it's not unambiguous what the Lisp version of an XLib
function returns (i.e., there is a somewhat arbitrary decision as to what
kind of value the lisp function returns). Anyhow this should be standardized
as far as I can see. My goal is that I can move source code to any CL
environment without any modifications to the code (Isn't that an obvious
goal!) so I want every necessary detail standardized.
I definitely agree with David's comments about Intellicorp's Commonwindows.
I don't think their proposal should be accepted as a Commonlisp standard,
but I do support the idea that all the vendors provide it. Obviously X
has many advantages as a standard, but I don't think that it should be
an official extension to the language. I view it like GKS .. I think there
should be standard language bindings for things like X, and even standard
user interface toolkits based on X (and COmmonloops). As far as I know
there is no official lisp language binding for GKS. I am not a GKS user so I
don't want to get into that specifically, but I think that it's important
that the Commonlisp world adopt industry standards and establish official
language bindings. Because X is probably going to be very widespread now,
I think this is crucial. I guess I should mention for those of you that
didn't hear the announcement, X has been endorsed as a standard by 11
companies including HP and DEC. Adobe also plans to make postscript extensions.
ALthough IBM and SUN were absent from the announcement, X is already
available on the IBM-RT and SUN workstations anyhow. SO there is no question
that X is here to stay for awhile. I think we should endorse it, though I
feel comfortable with SUN's position of not exclusively endorsing X. I
don't think we are ready for that and I don't think it's necessary. The
important thing is that it's available on most hardware and that all
commonlisp users have access to the standard version. Let's face it
de-facto standards work fairly well. At the same time, we should continue
exploring future directions wrt windowing environments and standards.
Finally, I think that Commonwindows can be implemented in X as one high-level
interface (both programmer and end-user interface as I see it). THis
should satisfy INtellicorp. ANd it buys everyone network-based and
remote graphics capabilities as well via X's functionality which is absent
in COmmonwindows as far as I know (As an aside I'm not an expert on the
Commonwindows proposal as IC refused to send me the document! That's a
good way to establish a standard. But I was told by a reliable source that
it's basically the same as the Interlisp window system which I am
intimately familiar with. No surprise if you have seen KEE demos on non-Xerox
hardware.)
Mark
-------
∂28-Jan-87 1246 primerd!doug@enx.prime.pdn Re: Lisp window systems standardization
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 12:45:53 PST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA20941; Wed, 28 Jan 87 15:32:42 EST
Received: by prime.uucp (1.1/SMI-3.0DEV3)
id AA27090; Wed, 28 Jan 87 14:19:09 EST
Message-Id: <8701281919.AA27090@prime.uucp>
Received: (from user DOUG) by ENX.Prime.PDN; 28 Jan 87 13:31:34 EDT
Subject: Re: Lisp window systems standardization
To: cl-windows@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 28 Jan 87 13:31:35 EDT
I believe that it is far too early to standardize a window system for
CommonLISP. Some progress has been made in the general window arena
in that X has been accepted by a large audience as a good window
server. This actually doesn't affect the kind of window system that
people want to use from a language like LISP.
A LISP window system would provide higher level concepts for the programmer
to use in the presentation of data and the processing of input from the
user. The programmer in such a system would generally want insulation
from the details of the implementation. Hopefully such a system could
exist equally well on X or some other system such as NEWS with minimal
changes to representation of basic objects (icons, fonts, etc.).
As RWS points out such a system would probably use object programming
(as indicated by Symbolics' success in this area).
It seems that this is a ripe area for experimentation and that folks
like David Martin (BOOL) are doing just that sort of experimentation.
This isn't a time where the experimentation has yielded the kind
of results where one can produce a standard.
Cheers,
Doug
(dougr@eddie.mit.edu <- Despite my apparent return address).
∂28-Jan-87 1356 FAHLMAN@C.CS.CMU.EDU Lisp interfaces to X
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 13:55:46 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 28 Jan 87 16:55:03-EST
Date: Wed, 28 Jan 1987 16:54 EST
Message-ID: <FAHLMAN.12274607897.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Lisp interfaces to X
In-reply-to: Msg of 28 Jan 1987 15:40-EST from Mark Richer <RICHER at SUMEX-AIM.STANFORD.EDU>
Let's be careful with this word "standard".
There is no chance whatsoever that Common Lisp is going to require X, or
anything like it, in the forseeable future. Common Lisp runs on all
sorts of machines: mainframes, PC-oids, and machines that have never
heard of graphics, let alone X. Also, X is very new, X11 is not out
yet, the Common Lisp Object Standard is not out yet, and I don't think
any of us has enough experience with this to know what kind of
high-level interface we really want on multiple-process,
multiple-language workstations. Before you can even think about a
standard, you've got to have a consensus.
On the other hand, a lot of Common Lisp work will be done on unix-based
machines that support X, interfaces to X will be built, and it would be
too bad if each of these Common-Lisp-to-X interfaces were gratuitously
different. So it is worthwhile to try to coordinate our efforts here;
by so doing, we can minimize duplication of effort and maximize the
portability of code between these X-based systems.
Something like the following sequence of events might make sense:
1. We try to agree among ourselves on what the lowest-level X11
interface should look like, for those systems that have one. We try to
get our respective Lisp systems to implement this agreement. This
interface may or may not involve object-oriented stuff, but it should
not get into uncharted and controversial territory. Code will be
portable on top of this interface. If successful, this will eventually
become an informal de facto standard for low-level Common-Lisp-to-X
interface, but not a required part of the Common Lisp standard.
2. We should experiment with higher-level abstractions and packages on
top of this common base, sharing code as much as possible. Probably one
approach will eventually emerge as "the right thing"; maybe a couple of
competing systems will emerge. In order to gain acceptance, such
systems must be readily available on a lot of machines; if people can't
get the sources to a system and run it on their own machines, that
system will contribute very little to any emerging consensus.
3. If a consensus emerges on higher-level window and graphics concepts,
and some portable code is available to implement these concepts, then we
can start talking about a standard in this area. It may be that, at
some suitable level of abstraction, the specific dependence on X will
disappear. But this will not happen soon, and arguing about the shape
of this ultimate window/graphics systems is probably not fruitful right
now.
-- Scott
∂28-Jan-87 1429 TAYLOR%PLU@ames-io.ARPA Window Systems Survey
Received: from AMES-IO.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jan 87 14:28:21 PST
Received: from PLU by IO with VMS ;
Wed, 28 Jan 87 12:55:21 PST
Date: Wed, 28 Jan 87 12:55:21 PST
From: TAYLOR%PLU@ames-io.ARPA
Subject: Window Systems Survey
To: @w_survey
The following request was posted to AILIST & SLUG bulletin boards:
***************>>>>>
We have been developing a user interface for a planning/scheduling
application on the Symbolics, using Version 6.1 windows and flavors.
For future long term development of the user interface, we are
considering a possible change of the window system, before converting
to Genera 7.0 Dynamic windows and Presentation types. We have heard
mention of XWINDOWS and are interested in knowing about it and other
"generic" window systems and the trade-offs between specialized
features and portability.
Issues we are looking at:
o will window system be compatible with a future Common
lisp window standard
o will window system be portable between lisp machines and
AI work stations, e.g. Symbolics, TI, LMI, Xerox, Sun, ..
o how much conversion will be required to go from current
implementation, now running under Genera 7.0, to a new
window system
o what are advantages/disadvantages of potential window
systems as far as ease of implementation, facilities
available to present information to user, use of object
oriented techniques, etc
o availability of potential window systems on the Symbolics
Opinions and recommendations are solicited from Lisp machine users
as to their experience and preferences. Please respond by e-mail.
I will summarize for this bboard if requested and sufficient responses
are received.
**********<<<<<<<<<
Below are the significant responses (total responses were 10). This
summary is being posted to SLUG, Common-windows, Xpert (XWINDOWS) and
those who specifically requested it.
--------------------------------------------------------
From: James J Dempsey <jjd@ALEXANDER.BBN.COM>
Do you ask about X windows because you have heard of someone porting X
windows to the Symbolics?
If it were up to me, I would always use a portable standard (like X
windows) instead of a propriatary system (like Symbolics Window
system). Right now our application is tied to symbolics machines and
can't be ported, mainly because of our use of the window system.
Intellicorp wrote their own window system so that KEE would be
portable across machines, including the window system.
If you have heard of X being available (or under development) for the
Symbolics, I would appreciate hearing about it.
--Jim Dempsey--
BBN Communications
[ I did not hear of X being available on the Symbolics and I imagine the
largest stumbling block to be that X is written in the C language and
no C compiler exists for the Symbolics (correct ?)- Will]
------*******
From: Connie K. Brede <BREDE@SRI-STRIPE.ARPA>
I have no info to offer concerning your query, but am very much interested in
the recommendations you recieve. I have been working on user interface
facilities for applications on Symbolics release 6.x and Xerox/InterLisp-D, and
i would really like to find a common base to work from.
------*******
From: mike@etl-ai.ARPA (Mike McDonnell)
As far as I know, the window system of the Symbolics is the part of the system
that is *least* likely to be compatible with some future Common-Lisp standard.
The single point of compatibility that is forseeable is that any window
standard will almost certainly be based on the yet-to-be-decided object-
based CL standard. A good bet is that this object standard will much resemble
the Genera 7 "new flavors", but since Symbolics has not yet implemented their
window system in new flavors, any future standard will almost certainly be
incompatible with the present Symbolics window system.
So, then, is there a portable window system that is good on the Symbolics and
on other machines? In particular, what about X windows? Sorry, but as far
as I know (and I don't know much) there are too many differences in the whole
philosophy and design of flavor-based window systems and other kinds of
windows, such as X windows, for there to be a means of changing one into the
other. Because of this bleak situation, there are several more-or-less heroic
attempts to bridge this yawning gap. Typical is Intellicorp's [usual
disclaimer] implementation of their own window system on top of whatever is
available on the host system so that they can port their products to various
systems while still programming to a consistent interface. This is hardly
ideal though, since the extra layer slows things down and adds complexity. And
developers still have to master each of the underlying window systems anyway.
My prejudice is that objects are the ideal paradigm for window systems since
inheritance allows you to easily extend and tailor the functionality of
windows. I do most of my programming on a Symbolics [disclaimer], but I have
done a lot of Unix programming too and do understand the differences between
the methods used on these systems. Because of this, I would stay with
flavor-based windows with the vastly increased programmer productivity in that
environment, and take my chances with the future. Immediate commercial
considerations would make me change my mind, but we don't have commercial
considerations in the government :-).
------*******
From: Arun Welch <Welch%OSU-20@ohio-state.ARPA>
Lisp Systems Programmer, Lab for AI Research, Ohio State University
We've been looking at pretty much the same issues here, and it looks
pretty bad. Most of our software has been written on Xerox
d-machines, and we're in the process of re-writing it with portability
in mind. From my experience, here are some answers to your questions:
>
> o will window system be compatible with a future Common
> lisp window standard
Last I heard, the work on a window system standard (Common-Windows)
was bogged down. If you want to get on the mailing list, the address
is CL-WINDOWS-REQUEST@SAIL.STANFORD.EDU. Otherwise, I haven't seen
any compatibility between any of the window systems. The Lucid and
the Xerox windows share a windowing philosophy which is different from
that shared by the TI and Symbolics worlds, but that's about as far as
it goes. The TI and Symbolics are fairly close, as of version 6, but
were diverging fast...
> o will window system be portable between lisp machines and
> AI work stations, e.g. Symbolics, TI, LMI, Xerox, Sun, ..
Nope.
> o how much conversion will be required to go from current
> implementation, now running under Genera 7.0, to a new
> window system
I don't know about this one.
> o what are advantages/disadvantages of potential window
> systems as far as ease of implementation, facilities
> available to present information to user, use of object
> oriented techniques, etc
I'm a fanatic about the Interlisp window philosophy, myself, so I'm
warning you that I'm biased towards them as far as ease of use, etc. goes.
> o availability of potential window systems on the Symbolics
>
Once again, I don't know.
I wish I could help you more. We're in the *early* development stages
of developing our own portable window system, overlaid on the inherent
window systems of the target machines, using either CommonLoops or a
reasonable subset thereoff. However, since CommonLoops itself is in a
fair state of flux, even that is up in the air. Hopefully I'll have
something more in 6-9 months (I better :-).
Intellicorp has done some work in this area, but aren't releasing
anything. I have a copy of their draft manual, dated June 1986, but
haven't heard about any updates, nor is it complete. I don't know
about the availability of the manual, either (As I said, I got a draft
copy). I don't know how much has been implemented, either.
I'd be interested in any info you get. I hope it doesn't end up that
a lot of people are duplicating work all over the place.
------*******
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
There is a mailing list on commonlisp windows that discusses issues
such as the ones you raise and a bunch of people that use or are interestsed
in X windows are on the list. I have remailed your message, perhaps you will
get a response from someone there. It would be appropriate if this
discussion moved there.
The list is cl-windows@sail.stanford.edu To get on send a request to
cl-windows-request@sail.stanford.edu.
There is also a list on X called xpert@athena.mit.edu. Send to xpert-request
to get on that one.
------*******
Phone call from Ken Tidwell, Intellicorp (415)965-5500
[ If there are any inaccuracies in the following condensation of
the conversation, I apologize to Ken and would appreciate being
corrected - Will]
Ken is one of the designers of Intellicorp's Common Windows (CW).
CW is a part of KEE 3.0 (Relase 6.1 Symbolics).
KEE 3.0300 (Genera 7.0 Symbolics) will be out in 2-3 months.
NeWS (Sun) & XWINDOWS are C based. XWINDOWS is very basic, has no tool
kit facilities - is available on HP, Sun, Dec. CW is common
lisp based & is proposed as a standard for common lisp windows. CW is not
currently sold separately from KEE 3. KEE 3 is available on Symbolics,
LMI, TI, Xerox, Sun, Vaxstation and IBM/PC-VAX.
Franz, Inc. and Lucid are working on common lisp based window systems
which may be available by the end of 1987. Sun is also working on a
window system, based on NeWS.
Requests to Intellicorp for possible unbundling of CW from KEE should
be directed to Dan Gottlieb - (415)965-5500
------*******
From: ihnp4!mmm!rouner@ucbvax.Berkeley.EDU (Bill Rouner)
Organization: Software & Electronics Resource Center/3M
Bill Rouner, SERC SW R&D, 3M Company (612)733-9086
We have the same concerns as you do. An additional concern is legal
protection (copyright or patent). One proposal I encountered was the
development of the APPLE Macintosh window toolbox calls in Common Lisp.
While the Macintosh interface is widely accepted among the user community,
we shied away because of the potential legal liability.
There are two window facilities that are being promoted: SUN windowing
facility and the recently introduced KEE Pictures window facility from
Intellicorp. At this time neither appear to be making headway. It seems
unlikely that any window system will get firmly established until a "standard"
object oriented facility (e.g. CommonLOOPS, Symbolics new FLAVOR) is adopted.
------*******
Feedback on this information would be appreciated - Will
--------------------------------------------------------------------------
Will Taylor - Sterling Software, MS 244-7,
NASA-Ames Research Center, Moffett Field, CA 94035
arpanet: taylor%plu@ames-io.ARPA
usenet: ..!ames!plu.decnet!taylor
phone : (415)694-6525
∂28-Jan-87 1430 RICHER@SUMEX-AIM.STANFORD.EDU Re: Lisp interfaces to X
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 14:30:25 PST
Date: Wed 28 Jan 87 14:30:09-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Lisp interfaces to X
To: Fahlman@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12274607897.BABYL@C.CS.CMU.EDU>
Message-ID: <12274614300.81.RICHER@SUMEX-AIM.STANFORD.EDU>
I agree with Scott 100%. If I didn't make it clear: I DO NOT THINK THAT
CL SHOULD REQUIRE X. But I do think there should be a standard
programmer interface on all hardware. And I want the code portable not
just to unix machines but to lisp machines and VMS on the Vax, etc. I
think that is what SCott is saying also(I hope).
Hopefully, we can reach consensus on this list wrt this matter, but I'd
really like to see the hardware and software vendors endorse and support
this also .. otherwise it's a drag. For example, let's say company A
supports X and provides a lisp interface. They also provide some neat
tools. Meanwhile, someone offers me some neat CL/X stuff they have done,
but they are working on top of a slightly different X interface. It
would be a senseless pain to have to figure out and make the modifications.
Obviously it wouldn't be a great intellectual challenge to do this, but
it's the kind of time-consuming and tedious work I think we all want to
avoid. By the way, I wouldn't be bringing the issue up if I didn't see that
different interfaces are being developed independently already.
After we standardize on a low-level interface to X, I agree then we can
take more time to discuss higher-level interfaces. BUt even for a low-level
interface we need to consider what Scheifler said: perhaps, corresponding
lisp functions for every C function in Xlib may not be a good idea as
the low-level interface. However, I think we should proceed and agree
on a foreign function call interface for V11/unix people in the meantime,
but we need to resolve the issue Bob raised soon.
Mark
-------
∂29-Jan-87 1114 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Me 'n X (ignore if you like)
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87 06:31:12 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 09:30-EST
Date: Thu, 29 Jan 87 09:32 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Me 'n X (ignore if you like)
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870129093237.6.RWS@KILLINGTON.LCS.MIT.EDU>
Comment: Remailed at SU-AI after delay caused by mailing list error.
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
My understanding is that you are implementing X11 on a lisp machine ...
Just to set the record straight, I am engaged (as time permits) in building
a Version 11 server in (extended) CL, initially targeted at running on Symbolics
and TI lispms executing inside one of their system's windows. I have also
been experimenting with slipping X in under the covers of the existing Symbolics
window system, so that "native" applications can be used across a network
without any application modifications. I am NOT engaged in building a programming
interface to X.
From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
I would like to know what you (specifically) and others want to see ...
There are about 37 other aspects of X (plus my "real" research) keeping me busy;
I don't have the time to design a Lisp interface (but I would like to stay tuned
in and offer my two cents when I can), and I believe there are people out there
who can do a better job of it than me anyway.
∂29-Jan-87 1114 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU foreign function interfaces
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87 06:58:20 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 09:58-EST
Date: Thu, 29 Jan 87 09:59 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: foreign function interfaces
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870129095954.8.RWS@KILLINGTON.LCS.MIT.EDU>
I will repeat myself: I don't really understand why people think a ffi
is either "the easy thing" or "the right thing". Most of the C Xlib is
stupid repetitive packet formatting, which can be almost completely
replaced in Lisp with a few well-chosen macros. If you just want a
straight native Lisp equivalent of Xlib, it could easily be put together
in a week (I assert, having crufted lots of it together for V10, and
having done the equivalent on the V11 server side "for real" recently),
and you end up with something that is FAR more portable.
∂29-Jan-87 1114 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU X interface
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87 07:47:17 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 10:46-EST
Date: Thu, 29 Jan 87 10:48 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X interface
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870129104842.9.RWS@KILLINGTON.LCS.MIT.EDU>
The C Xlib was designed without any thought given to multiple execution
threads. I hope a Lisp interface will be designed with concurrency in
mind (but without requiring multiple threads); I would hate to see two
different interfaces evolve.
Just as one example, note that X has asynchronous errors; will the
interface undertake to dispatch errors back to the appropriate thread?
In the Unix world one is almost forced to think of IPC as the only link
to an X server (console). In a lispm world (which is what we all
desire, right? :-) , it is natural to assume that (eventually) the most
commonly accessed X server will be just another collection of objects
and threads in your address space. One would like clients to have
direct access to the server objects, without imposing a (shared-memory)
channel between the client and some server thread. This certainly has
implications for the structure of the server, but it would seem to
affect the structure of a programming interface as well. For example,
will you want local clients to pay the overhead of the resource-id to
server-object translation, or of packet formatting? If you believe the
local case should be have more "direct" links, then it would seem you
want the programming interface to present some sort of (object)
abstraction to resources, since resource ids alone won't be the only
coin for communication.
However, there are some problems with defining an interface in terms of
anything but resource ids. (These same problems came up in early C Xlib
discussions, which is why Xlib looks the way it does.) Resource id
transmission is not a one way street; there are various ways in which
the server can hand them back to you. For example, device events are
reported not only with the "event" window id but also with a child
window id. If you try to hide resource ids from the application, then
any ids coming back from the server should also be hidden, which means
you need a reverse mapping. How is this mapping maintained? How is it
garbage collected? If the application-level manifestation of the
resource has embedded state, how do you decide which thread's or
activity's manifestation to reverse map to?
This in part depends on your point of view about how event dispatching
should work. Is there a single event queue that threads pull things off
of, or are events automatically dispatched to per-window or per-thread
queues, or does each window have associated with it a "call-back"
function for each event type (and what thread is that function called
within?)
∂29-Jan-87 1212 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU foreign function interfaces
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87 06:58:20 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 09:58-EST
Date: Thu, 29 Jan 87 09:59 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: foreign function interfaces
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870129095954.8.RWS@KILLINGTON.LCS.MIT.EDU>
I will repeat myself: I don't really understand why people think a ffi
is either "the easy thing" or "the right thing". Most of the C Xlib is
stupid repetitive packet formatting, which can be almost completely
replaced in Lisp with a few well-chosen macros. If you just want a
straight native Lisp equivalent of Xlib, it could easily be put together
in a week (I assert, having crufted lots of it together for V10, and
having done the equivalent on the V11 server side "for real" recently),
and you end up with something that is FAR more portable.
∂30-Jan-87 1325 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Lisp interfaces to X
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 30 Jan 87 12:59:21 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 44459; Wed 28-Jan-87 17:11:09 EST
Date: Wed, 28 Jan 87 17:08 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Lisp interfaces to X
To: RICHER@SUMEX-AIM.STANFORD.EDU, dcmartin@INGRES.BERKELEY.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12274594352.81.RICHER@SUMEX-AIM.STANFORD.EDU>
Message-ID: <870128170819.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Is it possible to get an up-to-date specification of Intellicorp's
"Commonwindows" interface?
∂31-Jan-87 0956 meltsner@athena.MIT.EDU Vendors and X + LISP
Received: from CHARON.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Jan 87 09:56:47 PST
Received: by CHARON (5.45/4.7)
id AA03272; Sat, 31 Jan 87 11:57:28 EST
Message-Id: <8701311657.AA03272@CHARON>
To: cl-windows@sail.stanford.edu
Subject: Vendors and X + LISP
Date: Sat, 31 Jan 87 11:57:24 -0500
From: meltsner@athena.MIT.EDU
One should not ignore the fact that Common LISP vendors may wish to
support X only as part of their existing window system. For example,
Lucid's sales rep told me they do plan to make an X version of their
window system as soon as their current backlog of work is completed.
Unfortunately, I gather this will be simply their generic window system
(same on Apollos, RT/AIX, Suns, etc.) rather than a true X port. Now,
while the former means more transportability of code for Lucid customers,
the latter would be more what (I think) people on this list want.
Ken
∂04-Feb-87 1547 Ehrlich@YUKON.SCRC.Symbolics.COM Window Systems Survey
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 4 Feb 87 15:46:56 PST
Received: from SWAN.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 158862; Wed 4-Feb-87 18:43:14 EST
Date: Wed, 4 Feb 87 18:42 EST
From: Kate Ehrlich <Ehrlich@YUKON.SCRC.Symbolics.COM>
Subject: Window Systems Survey
To: cl-windows@SU-AI.ARPA, slug@UTEXAS-20.ARPA
cc: TAYLOR%PLU@AMES-IO.ARPA, ehrlich@YUKON.SCRC.Symbolics.COM
Supersedes: <870204154907.1.EHRLICH@SWAN.SCRC.Symbolics.COM>
Message-ID: <870204184256.2.EHRLICH@SWAN.SCRC.Symbolics.COM>
From: TAYLOR%PLU@ames-io.ARPA
We have been developing a user interface for a planning/scheduling
application on the Symbolics, using Version 6.1 windows and flavors.
For future long term development of the user interface, we are
considering a possible change of the window system, before converting
to Genera 7.0 Dynamic windows and Presentation types. We have heard
mention of XWINDOWS and are interested in knowing about it and other
"generic" window systems and the trade-offs between specialized
features and portability.
In order to evaluate various window systems, specifically the Genera 7.0
Window System and X-Windows, it is necessary for you to appreciate that
X-Windows operates at a much lower level of abstraction than the Genera
7.0 Window System. This means that far from the various systems being
antagonistic, they can actually work together, albeit at different
levels. In the current Genera 7.0 Window System the lower levels are
handled by sheets.
The Genera 7.0 Window System is specifically designed to allow the
application program to be written at a higher level of abstraction,
insulating a programmer from changes to the substrate. That is, changes
to the substrate should have minimal or no effect on your existing
window system code. Symbolics intends to support its higher level window
system on top of any Common Lisp standard or a Common Lisp standard
built on top of an X virtual console specification.
We are working with people from Xerox and Lucid on what is now called
the "Common Lisp Object System", a proposed object-oriented programming
standard based on ideas from both "CommonLoops" and New Flavors. We are
also carefully monitoring work on X-Windows and Common Lisp standard
window systems. Symbolics has a long history of actively promoting and
contributing to standards. Programmers using the Genera 7.0 Window
System will not be locked out of future window systems standards.
Incidentally, the issue of C raised by one of your respondents is
largely irrelevant. X is a standard, for which there is an
implementation in C. Any Symbolics support for X would be in Lisp.
∂06-Feb-87 1311 BATALI@SPAR-20.ARPA please add me
Received: from [128.58.1.2] by SAIL.STANFORD.EDU with TCP; 6 Feb 87 13:03:10 PST
Date: Fri, 6 Feb 1987 11:28 PST
From: John Batali <BATALI at FLAIR-20>
To: cl-windows at sail
subject: please add me
reply-to: batali@mit-mc
to the cl-windows mailing list.
John Batali
BATALI@MIT-MC
∂11-Feb-87 1658 DON%atc.bendix.com@RELAY.CS.NET Bulletin board subscription
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 11 Feb 87 16:57:45 PST
Received: from relay2.cs.net by RELAY.CS.NET id cl00964; 11 Feb 87 15:37 EST
Received: from atc.bendix.com by csnet-relay.csnet id aa09198;
11 Feb 87 13:45 EST
Date: Wed, 11 Feb 87 08:30 EST
From: DON%atc.bendix.com@RELAY.CS.NET
To: common-lisp-request%su-ai.arpa@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU,
works%rutgers.arpa@RELAY.CS.NET
Subject: Bulletin board subscription
X-VMS-To: IN%"common-lisp-request@su-ai.arpa",IN%"cl-windows@sail.stanford.edu", IN%"works@rutgers.arpa"
Please add
aisubscriber@atc.bendix.com
or aisubscriber%atc.bendix.com@csnet-relay.csnet
to your bulletin board list. (Use whichever address your site supports.)
Don Mitchell
∂13-Feb-87 0636 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU X atoms, a poll
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87 06:35:55 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Feb 87 09:35-EST
Date: Fri, 13 Feb 87 09:38 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X atoms, a poll
To: cl-windows@SAIL.STANFORD.EDU
cc: xpert@ATHENA.MIT.EDU
Message-ID: <870213093807.6.RWS@KILLINGTON.LCS.MIT.EDU>
X Version 11 has a concept of "atoms", which act somewhat like
symbols in Lisp. Atoms get used to name various things, like
window properties. The protocol specifies that upper/lower
case matters when interning an atom. The protocol also gives
numerous predefined atoms that are expected to be commonly
used, to avoid needless queries from clients to discover their
interned numeric value.
X/V11 is going into alpha test with the following sorts of atoms:
Bitmap PointSize StrikeoutAscent
Note the use of case.
It has been suggested that in the Lisp interface to X it would
be natural and useful to use (or at least allow) real keyword
symbols everywhere, and to hide the existence of atoms "inside"
the Xlib-equivalent interface by maintaing a (hash) table mapping
between keywords and X numeric atom values. For this to be "natural",
I assume that keywords like:
:bitmap :point-size :strikeout-ascent
would be preferable to:
:|Bitmap| :|PointSize| :|StrikeoutAscent|
meaning the more "natural" atom names would be:
BITMAP POINT-SIZE STRIKEOUT-ASCENT
or
bitmap point-size strikeout-ascent
The problem is that C programmers want their #define names to
match the corresponding string values, and you can't use hyphens
in C names, and on the Lisp side the mapping needs to be 1-to-1 and
reversible. A suggested compromise was to use underscore, which is
legal in C, but the problem is that underscore is left open to
reinterpretation in CL. However, in Lisp we could use a reversible
mapping of always replacing hyphens with underscores when converting
from keyword to atom, and replacing underscores with hyphens when
converting from atom to keyword.
It is not too late to change the pre-defined atoms in X. All
suggestions and comments on the proposed underscore/hyphen
solution, or alternate proposals, would be extremely welcome.
∂13-Feb-87 0808 FAHLMAN@C.CS.CMU.EDU X atoms, a poll
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87 08:08:02 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Feb 87 11:06:43-EST
Date: Fri, 13 Feb 1987 11:06 EST
Message-ID: <FAHLMAN.12278738788.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
Subject: X atoms, a poll
In-reply-to: Msg of 13 Feb 1987 09:38-EST from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
This is a special case of the problem of building Lisp-to-C interfaces
in general. We've been doing this at CMU for a while, using a variety
of tools, collectively called "Matchmaker".
X11 is being designed with some consideration for Lisp built-in, but the
overwhelming majority of C programs are not. So automatic
interface-building tools need some automated way of handling the
"BiteTheBag" naming convention that is common among users of C and
Pascal. We can't depend in general on C programmers to use
"Bite_The_Bag", so none of our tools assume this.
Our solution on name conversion has been to use the C names as is,
though case information is lost, rather than getting into the game of
hacking hyphens and underscores. So the C symbols named "BitMap",
"PointSize", and "StrikeoutAscent" become ":bitmap", ":pointsize", and
":strikeoutascent". That's a bit ugly, but workable, and less confusing
than using underscores on the C side and hyphens on the Lisp side.
The one strong assumption here is that the C people will not depend on
case for anything more than decoration. If the C program has two
distinct symbols named "Foobar" and FooBar", then we lose. The best we
can do is to catch these cases and ask the user what Lisp-side names he
wants to use for the two conflicting symbols. I hope that, whatever is
decided about naming conventions, the X11 designers will not define
distinct symbols that differ in case only.
An alternative approach is to automatically insert a hyphen whenever the
C version has an upper-case character that is not at the start of the
word. So "IgnoreThisObject" becomes ":ingore-this-object". That's a
bit more readable, is a reversible transformation, and doesn't require
the C people to alter their naming conventions. It does require the C
people to be totally consistent in their use of the "FooBarBarf" naming
style. Something like "README" causes b-i-g trouble. We considered
doing this in our own Lisp-to-C interfaces, but decided it wasn't worth
putting Matchmaker to the extra trouble.
-- Scott
∂13-Feb-87 0859 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU X atoms, a poll
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87 08:59:00 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Feb 87 11:48-EST
Date: Fri, 13 Feb 87 11:51 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X atoms, a poll
To: Fahlman@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
In-Reply-To: <FAHLMAN.12278738788.BABYL@C.CS.CMU.EDU>
Message-ID: <870213115105.3.RWS@KILLINGTON.LCS.MIT.EDU>
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I hope that, whatever is
decided about naming conventions, the X11 designers will not define
distinct symbols that differ in case only.
All of the pre-defined atoms will be consistent, but we can't control
what users will use in addition.
So the C symbols named "BitMap",
"PointSize", and "StrikeoutAscent" become ":bitmap", ":pointsize", and
":strikeoutascent". That's a bit ugly, but workable ...
An alternative approach is to automatically insert a hyphen whenever the
C version has an upper-case character that is not at the start of the
word. So "IgnoreThisObject" becomes ":ignore-this-object". That's a
bit more readable, is a reversible transformation, and doesn't require
the C people to alter their naming conventions.
The first approach is not only ugly, but doesn't work, and I'm not sure
the second is reversible in the sense I had in mind. Note there is no
static interface between C and Lisp here, as there is in Matchmaker.
When a Lisp programmer wants to store a property, s/he doesn't want to
have to declare a binding to some C programmer's naming convention; the
whole point is to reduce the burden, not increase it. When reading a
list of window properties out of a server, you don't know what language
created them. For an automatic keyword<->atom mapping to work, every
distinct X atom must have a distinct Lisp keyword, and which also means
every distinct Lisp keyword must have a distinct X atom.
∂13-Feb-87 0959 RAM@C.CS.CMU.EDU X atoms, a poll
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87 09:58:57 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 13 Feb 87 12:59:19-EST
Date: Fri, 13 Feb 1987 12:59 EST
Message-ID: <RAM.12278759272.BABYL@>
From: Rob MacLachlan <RAM@λλ>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
Subject: X atoms, a poll
In-reply-to: Msg of 13 Feb 1987 09:38-EST from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
I would say use underscores and single case, but I agree with Scott
that it isn't a make or break issue since an interface isomorphic to a
non-lisp system is going to be ugly anyway. For example, in the case
of properties, you are already going to have to explicitly declare a
to-lisp translation for each property so that the system knows how to
lispify the property value.
I don't see why you say that underscores are "subject to
reinterpretation", and thus unsuitable for use in symbols. It is true
that underscores may appear in potential numbers (which cannot be read
without escapes) but that doesn't stop you from interning them. The
whole idea behind specifying potential numbers is that chops off a
piece of syntax for future use with the understanding that anything
else will always be symbol.
Although it would surely be amusing explaining the potential number
rules to C programmers, I believe that if you stick to legal C
identifiers, then the only way that you could come up with a potential
number is if you began the name with an underscore and followed it by
letters and digits without any two adjacent letters. C programmers
will screw us without trying nearly that hard.
Rob
∂13-Feb-87 1221 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU underscores
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87 12:21:35 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Feb 87 15:21-EST
Date: Fri, 13 Feb 87 15:23 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: underscores
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12278759272.BABYL@>
Message-ID: <870213152325.5.RWS@KILLINGTON.LCS.MIT.EDU>
From: Rob MacLachlan <RAM@c.cs.cmu.edu>
I don't see why you say that underscores are "subject to
reinterpretation", and thus unsuitable for use in symbols.
CLtL (p. 21) states "↑ and _ are not yet used in Common Lisp, but are
part of the syntax reserved for tokens, and are reserved to implementors".
I take this to mean that they are not necessarily valid as symbol
characters without quoting. For example, in Symbolics Genera 7.0,
I can type in :foo_bar but it prints as :|FOO_BAR|. Is there some
change that I don't know about, or am I misinterpreting something?
∂13-Feb-87 1228 FAHLMAN@C.CS.CMU.EDU X atoms, a poll
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87 12:27:46 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Feb 87 15:27:47-EST
Date: Fri, 13 Feb 1987 15:27 EST
Message-ID: <FAHLMAN.12278786314.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
Subject: X atoms, a poll
In-reply-to: Msg of 13 Feb 1987 11:51-EST from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
So the C symbols named "BitMap",
"PointSize", and "StrikeoutAscent" become ":bitmap", ":pointsize", and
":strikeoutascent". That's a bit ugly, but workable ...
An alternative approach is to automatically insert a hyphen whenever the
C version has an upper-case character that is not at the start of the
word...
The first approach is not only ugly, but doesn't work, and I'm not sure
the second is reversible in the sense I had in mind. Note there is no
static interface between C and Lisp here, as there is in Matchmaker.
When a Lisp programmer wants to store a property, s/he doesn't want to
have to declare a binding to some C programmer's naming convention; the
whole point is to reduce the burden, not increase it. When reading a
list of window properties out of a server, you don't know what language
created them. For an automatic keyword<->atom mapping to work, every
distinct X atom must have a distinct Lisp keyword, and which also means
every distinct Lisp keyword must have a distinct X atom.
I don't understand this. Why does it matter whether the interface is
static or dynamic? When a new "atom" is created, both the Lisp and C
spellings are registered in a hash table somewhere. (Under either of my
proposals, you could register the C spelling and generate the Lisp
spelling automatically from it.) In a Lisp program you will always see
the Lisp version; in a C program, you will always see the C version. If
an "atom" is passed across the Lisp-to-C interface, part of that process
is name-conversion of any atoms.
Are you suggesting that programmers will want to make up new atom-names
on the fly and then pass them back and forth between Lisp and C without
first registering these atoms somewhere? If atoms must be registered
with C (in order to be assigned a canonical identifier), the Lisp
version of the name can be created and registered at that time.
As seen from the Lisp side, it would be something like
(register-x-atom "FooBar" "BiteTheBaggie" "FlyingWombat")
=> (:foobar :bitethebaggie :flyingwombat)
(call-some-x-routine :foobar :bitethebaggie)
=> :flyingwombat
... or ...
(register-x-atom "FooBar" "BiteTheBaggie" "FlyingWombat")
=> (:foo-bar :bite-the-baggie :flying-wombat)
(call-some-x-routine :foo-bar :bite-the-baggie)
=> :flying-wombat
-- Scott
∂13-Feb-87 1249 Moon@STONY-BROOK.SCRC.Symbolics.COM X atoms, a poll
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 Feb 87 12:49:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 70517; Fri 13-Feb-87 15:46:36 EST
Date: Fri, 13 Feb 87 15:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: X atoms, a poll
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
In-Reply-To: <870213093807.6.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870213154626.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I don't see any strong reason to think that using Lisp keywords to
represent X atoms would be more efficient or more desirable than
using Lisp strings. There is a hash-table-based translation between
the Lisp and X worlds in either case. If you use strings, you don't
have to worry about mapping between two different casing/punctuating
conventions.
∂13-Feb-87 1345 RAM@C.CS.CMU.EDU underscores
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87 13:41:14 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 13 Feb 87 16:41:40-EST
Date: Fri, 13 Feb 1987 16:41 EST
Message-ID: <RAM.12278799760.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: underscores
In-reply-to: Msg of 13 Feb 1987 15:23-EST from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Well, this getting a bit off track for this list, but I think that the
answer is that the statement on page 21 is wrong or at least
misleading. I suspect that it predates the formalized notion of a
potential number, since that was a rather late addition. In any case,
many of the statements in the data types chapter are only partial
truths that serve as forward definitions so that we can give code
examples without precisely describing the reader and other parts of
the system first.
On 343, after saying that potential numbers and all-dots symbols are
unreadable symbols, it says "In all other cases the token is construed
as a symbol." This means that the reader can't complain if you type
:foo_bar, so it is perfectly legit in code.
The Symbolics printer may be correct, since on 367 where it is
discussing symbol printing rules, it requires that potential numbers
be escaped, but does not forbid gratuitous escaping. The fact that
some printers may escape unnecessarily shouldn't affect the semantics
of programs. Our printer only escapes potential numbers or symbols
that are otherwise unreadable.
Rob
∂19-Feb-87 1401 SPIRKOV%PLU@ames-io.ARPA please add me to the mailing list.
Received: from AMES-IO.ARPA by SAIL.STANFORD.EDU with TCP; 19 Feb 87 14:01:26 PST
Received: from PLU by IO with VMS ;
Thu, 19 Feb 87 13:58:24 PST
Date: Thu, 19 Feb 87 13:58:24 PST
From: SPIRKOV%PLU@ames-io.ARPA
Subject: please add me to the mailing list.
To: cl-windows@sail.stanford.edu
thank you.
Lilly Spirkovska
(spirkov@ames-pluto.arpa)
∂20-Feb-87 1555 TAYLOR%PLU@ames-io.ARPA CW Standard Status
Received: from AMES-IO.ARPA by SAIL.STANFORD.EDU with TCP; 20 Feb 87 15:55:22 PST
Received: from PLU by IO with VMS ;
Fri, 20 Feb 87 15:51:41 PST
Date: Fri, 20 Feb 87 15:51:41 PST
From: TAYLOR%PLU@ames-io.ARPA
Subject: CW Standard Status
To: cl-windows@sail.stanford.edu
I am interested in knowing the current status of selecting/defining
the Common Lisp Window standard; which of the following are in the
running for the standard: Symbolics Dynamic windows, Xerox Common
Loops/windows, Intellicorp Common Windows, X windows; how soon might
there be a decision ?
Thanks
--------------------------------------------------------------------------
Will Taylor - Sterling Software, MS 244-17,
NASA-Ames Research Center, Moffett Field, CA 94035
arpanet: taylor%plu@ames-io.ARPA
usenet: ..!ames!plu.decnet!taylor
phone : (415)694-6525
∂20-Feb-87 1944 FAHLMAN@C.CS.CMU.EDU CW Standard Status
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Feb 87 19:44:30 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 20 Feb 87 22:45:30-EST
Date: Fri, 20 Feb 1987 22:45 EST
Message-ID: <FAHLMAN.12280701008.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CW Standard Status
In-reply-to: Msg of 20 Feb 1987 18:51-EST from TAYLOR%PLU at ames-io.ARPA
In reply to: TAYLOR%PLU at ames-io.ARPA
Someone can correct me if this is wrong, but I believe it is the case
that nobody is currently working on a Common Lisp Window Standard. It
is my own belief that there will never be a single window standard for
all of the Common Lisp world. Such a thing would have to assume such a
low level of functionality that it would be worthless to most of us.
Not every machine running Common Lisp has a 2000x2000 24-plane color
display with real-time animation processor and 6-D 5-button bat (a
flying mouse); some machines still think they are talking to a teletype
or a deck of punched cards. It's hard to imagine any window standard
that can successfully span that kind of range.
What we might see sometime soon is an agreement -- maybe even an
official standard, but separate from the Common Lisp standard itself --
that specifies how Common Lisp talks to X if that's what you want to do.
In a couple of years, we might conceivably see a standard for connecting
Common Lisp to bit-mapped displays in general. This would have to be
defined at an abstract level that hides the details of the underlying
window manager. I don't think anyone knows how to do that right now,
without throwing out too much performance and flexibility in the
process.
The one thing that is absolutely certain is that no window system can
become any kind of standard for a large segment of the Common Lisp
community as long as it is proprietary or it is not easily portable to
other manufacturers' machines. I think the Symbolics and Intellicorp
window systems are ruled out on these grounds. I'm not sure about NEWS.
Is Sun passing out sources?
-- Scott
∂20-Feb-87 2354 edsel!bhopal!jonl@navajo.stanford.edu CW Standard Status
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Feb 87 23:54:33 PST
Received: by navajo.stanford.edu; Fri, 20 Feb 87 23:52:09 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA10673; Fri, 20 Feb 87 23:46:09 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA04446; Fri, 20 Feb 87 23:43:36 PST
Date: Fri, 20 Feb 87 23:43:36 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8702210743.AA04446@bhopal.edsel.com>
To: navajo!Fahlman%C.CS.CMU.EDU@navajo.stanford.edu
Cc: navajo!cl-windows%SAIL@navajo.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Fri, 20 Feb 1987 22:45 EST
Subject: CW Standard Status
One possibility for standardization in the Common Lisp world is merely
on a user-interface to a window system. Having seen the sentiment on
this list, and others, it seems that folks clearly want
(1) some sort of object-oriented interface
(2) and one which doesn't require research-project-level effort
to understand and use.
I guess that is why the disussions often tie together a potential window
system candidate with an o-o candidate.
Let us very-hypothetically suppose that some o-o standard emerges within
the next year; then what do you think? can a reasonable subset of window
capability be described in o-o terms? This would not be the kind of
standard where everybody had to implement the features described in the
interface, or were restricted to it; but rather it would say "if you
provide capability Z, then the user interface to it should look like ....".
I'd expect that over time, there would come to be a certain minimum
set of required capabilities that everyone agreed would have to be
implemented in order for a candidate to call itself a window system.
I think we can rule out the ASR/35 and friends as being any part of
a "window" system.
-- JonL --
∂21-Feb-87 0833 CS.WERTH@R20.UTEXAS.EDU please add me to the mailing list
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 21 Feb 87 08:17:06 PST
Date: Sat 21 Feb 87 10:18:11-CST
From: CS.WERTH@R20.UTEXAS.EDU
Subject: please add me to the mailing list
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12280838041.8.CS.WERTH@R20.UTEXAS.EDU>
-------
∂21-Feb-87 1523 RICHER@SUMEX-AIM.STANFORD.EDU CL-WINDOWS standards
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Feb 87 15:23:39 PST
Date: Sat 21 Feb 87 15:22:49-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: CL-WINDOWS standards
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12280915344.21.RICHER@SUMEX-AIM.STANFORD.EDU>
There is a cl-windows subcommittee as well as one on graphics, but it doesn't
seem if much progress has been made over the years. I assume that
there are people on this mailing list that are on those committees so
this discussion is probably being tracked and may have an impact.
I think we need to examine why we want standards. I can think of at
least four reasons all of which concern me as a direct result of
personal experiences:
(1) I have written code that I either want to move to another machine or
give away to someone who has a different machine.
(2) I want to obtain code that was written for another machine.
(3) I want to ask someone for advice on doing something, but they use
a different machine (or they want to ask me for help but I don't know
the details of their window system).
(4) For students it is very advantageous that textbooks, etc. all
refer to the same standard.
Obviously, there are tradeoffs. Standards also cause problems because
they become entrenched and make fundamental changes in the future
difficult on a widespread level. But contrary to how some people make
it out to be standards do NOT PREVENT language research. Just because
Commonlisp exists does not mean that research on lisp languages cannot
continue, i.e., anyone still has the right to develop an uncommonlisp.
However, I do agree we are not ready to define a commonlisp window
standard. And I'm not sure that window systems or graphics systems
should be designed at the language level. However, when they are
designed using a specific language the influence is often obvious
(e.g., unix and X being written in C). ALthough I would really like to
see a standard lisp interface to X, I think the issues are more
complicated than I anticipated. On the one hand, X solves a lot of
problems. It's available, it's public domain, it's been widely
adopted, and it does not require the adoption of the CL standard. X in lisp
addresses my concerns 1-4 for the most part and it will give us the
experience we need to work on future standards. The problem is that
there are some issues with regard to a lisp interace to X that remain
to be resolved:
(1) there is no Xlib written in Commonlisp that is widely available
(if one exists at all). Most people are using XLib written in C on
their unix workstations with a foreign function-call interface (ffi).
I agree with SCheifler and others that argue that this is not a great
way to go because an equivalent library can be written in Lisp that
may be more appropriate for lispers. Furthermore, lisp machine vendors
will follow a different course anyhow. What should Xlisplib look like?
If we don't want to just copy Xlib in C we have some things to
discuss. But I believe we should aim for a Portable Commonlisp (w/o
COmmonloops) Xlib that is public domain.
(2) What about objects? Do we all really agree on the idea that an oop
interface should be in the standard interface to X? I won't complain
personally, but is there anyone out there who objects (sorry for the
pun) to this? (a year or two ago there were people on this list who
found objects objectionable, and I know other lispers that still feel
that way). If we introduce objects into the interface at what level?
the library? the toolkit? Can we have a low-level interface to X that
can be implemented with or without objects? THis seems reasonable
given that Commonloops uses lisp function syntax. If the low-level
interface is all functions, why not? Perhaps we want two XLibs that
are functionally equivalent, one in pure CL and one in COmmonloops?
(3) What about a tool-kit or standard user-interface tools? THis is
going to take a while and personally I would object to not having
objects at this level. This tool-kit would be optional, i.e., you
could use the low-level lisp interface to X without using this
toolkit. How should the lisp toolkit relate to the C toolkit MIT,
DEC, HP, etc. are trying to agree on? One thing I do know is that this
toolkit needs to be easy to program and easy to customize. Or as ALan
Kay said (well I think he said this about programming languages, in
particular Smalltalk-72): "Simple things should be easy to
do and difficult things should be possible." Actually re-configuring
the interface to have a different look and feel should be relatively
easy for some known set of user-interface styles. We need to describe
an interface at an abstract level (e.g., highlighting is an
abstraction as opposed to inverting or boxing a text region which are
techniques).
Mark
-------
∂22-Feb-87 0846 FAHLMAN@C.CS.CMU.EDU CL-WINDOWS standards
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Feb 87 08:46:12 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Feb 87 11:47:12-EST
Date: Sun, 22 Feb 1987 11:47 EST
Message-ID: <FAHLMAN.12281105456.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: CL-WINDOWS standards
In-reply-to: Msg of 21 Feb 1987 18:22-EST from Mark Richer <RICHER at SUMEX-AIM.STANFORD.EDU>
Some opinions on the issues that Mark Richer raises:
1. Should we write a mostly-portable Xlib in Common Lisp, or should we
talk to the existing C-based Xlib via some foreign function call
interface? I would argue that we don't all need to do this the same
way. If we define a low-level Lisp interface that is analogous to the
Xlib interface that C provides (but with Lisp syntax and apropriate
mapping of data types into Lisp equivalents), then it can be left to
each implementor to decide whether this is done by calling linked-in C
routines, by calling Lisp equivalents to the C routines, or by packaging
up an IPC message and sending it to a remote server written in whatever
language. There has to be a server so that requests from distinct
processes can be coordinated, but the user doesn't need to know which
things are done in the server and which are done in his own process.
Nor does he have to know when some Lisp function that he has called
surreptitiously drops down into C or aseembler or microcode.
Since X is still evolving, and since the canonical implementation is
being done in C, the approach of linking in the C version of Xlib has
certain advantages to the implementor, at least on unix-based systems:
it becomes easy to track any changes with just a bit of fiddling with
the interfaces, and unintentional incompatibility is avoided.
In defining the lowest-level Lisp interface to X, there will be a great
temptation to break away from a straightforward mapping of the C calls
and to make the Lisp version nicer. This temptation will be especially
strong where the shortcomings of the C language make it necessary to do
something in a particularly ugly way. I think we should probably resist
this temptation. By mapping even the really dumb things in a
straightforward way, we make it possible to generate (much of) the
Lisp-to-X interface by some sort of mechanical translation from the C,
and we also lessen the burden on people who must move their code or
themselves back and forth between the two systems.
If this lowest-level "raw" interface between Lisp and X is not to our
liking, we can easily provide a body of portable Common Lisp code that
hides the C-derived ugliness and implements a nicer window-system
interface for most Lisp users. But I think that it is very important to
provide that lowest-level interface that maps the C calls very closely.
That will prevent the Lisp and C worlds from diverging, and it will make
it possible for some implementors to link in the C code in a
straightforward way.
2. What about objects? As long as there was no standard set of
object-oriented facilities within Common Lisp, no consensus on what
those facilities should look like, and no easy way to port the leading
contender (Flavors, at that time) to most Common Lisp workstations, it
seemed quite insane to propose a graphics standard that made significant
use of some object-oriented programming system. A consensus is now
developing around the new proposal for a Common Lisp Object System. It
seems clear that this will become part of the standard at some time in
the not-too-distant future and that implementations developed today in
PCL (Portable Common Loops) will be easy to port to the new standard,
once it is in place. So I no longer see any good reason to avoid making
use of objects in the graphics/windows area.
If the lowest-level interface is a nearly straightforward mapping of the
Xlib calls, as I have suggested above, then objects may be useful there
only in a degenerate defstruct-like sense. But for all the stuff built
on top of this layer, a complete object system will make a big diference
and it would make no sense to avoid using it.
3. What about toolkits? Upon reading the proposal for the
MIT/DEC/HP/whoever toolkit, what struck me was that about 80% of the
content of that proposal was an attempt to provide the C user with the
kind of flexible programming constructs that the Lisp user gets for free
-- especially the Lisp user who has an object system in his Lisp. The
spec proposes a few bits of user-level functionality that are worth
ripping off -- radio buttons, for example -- but to try to recreate in
Lisp the awkward way in which these things are provided would certainly
be counter-productive.
I think that the right goal here is to build a comprehensive, portable,
widely available Common Lisp toolkit on top of the primitive Lisp-to-X
interface, and to make sure that all of the popular user-level facilities
available in the C/X world have their counterparts in Lisp. Since we have
fewer low-level problems than the C people, and since we Lispers believe
that we have a much superior programming environment, we may soon find
that most of the innovation at the toolkit level is occurring on the
Lisp side, and it is the C people who are struggling to keep up.
-- Scott
∂22-Feb-87 1741 FAHLMAN@C.CS.CMU.EDU CW Standard Status
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Feb 87 17:41:49 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Feb 87 20:42:06-EST
Date: Sun, 22 Feb 1987 20:42 EST
Message-ID: <FAHLMAN.12281202834.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: edsel!bhopal!jonl@λnavajo.stanford.edu (Jon L White)λ
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: CW Standard Status
In-reply-to: Msg of 21 Feb 1987 02:43-EST from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
Sure, given an object-oriented standard, it's just a matter of figuring
out what higher-level abstractions are most appropriate and convenient
for a graphics/windows interface. If a consensus emerges about that,
then it's just a small matter of turning that consensus into a formal
standard. In order for this consensus to develop, we need some
experience, some good ideas, someone to work out a coherent proposal,
and someone to implement that proposal in reasonably portable
public-domain code.
I think that this may eventually happen. I don't know how long it will
take. Most of the groups I know about are just starting to experiment
with this stuff. Maybe there are segments of the Lisp community that
already have enough experience with objects and graphics to understand
what a really good set of abstractions would look like. If that same
set of people have the time and motivation to produce a proposal and
supporting code, then we could make very fast progress; if not, then
we're in for a couple of years of experimentation. If most of us can
work on a shared low-level substrate such as X, then the experimentation
will go more quickly because we can share what we develop.
-- Scott
∂23-Feb-87 0333 mcvax!inria!inria.inria.fr!devin@seismo.CSS.GOV change me
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 23 Feb 87 03:33:41 PST
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA17292; Mon, 23 Feb 87 06:34:19 EST
Received: by mcvax.cwi.nl; Mon, 23 Feb 87 12:25:58 +0100 (MET)
Received: by inria.inria.fr; Mon, 23 Feb 87 12:03:50 +0100 (MET)
Date: Mon, 23 Feb 87 12:03:50 +0100
From: mcvax!inria!inria.inria.fr!devin@seismo.CSS.GOV (Matthieu Devin)
Message-Id: <8702231103.AA06752@inria.inria.fr>
To: cl-windows@sail.stanford.edu
Subject: change me
could you please change inria!devin to inria!cl-windows in the mailinglist
please?
∂23-Feb-87 0813 dcmartin@ingres.berkeley.edu X/Common LISP interface
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87 08:13:30 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
id AA28193; Sun, 22 Feb 87 18:07:28 PST
Message-Id: <8702230207.AA28193@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Cc: cl-windows@sail.stanford.edu
Precedence: priority-mail
In-Reply-To: Your message of Sun, 22 Feb 1987 20:42 EST
Subject: X/Common LISP interface
Date: 22 Feb 87 18:07:26 PST (Sun)
Sender: dcmartin@ingres.berkeley.edu
Speaking of low-level X interfaces for Common LISP... that is exactly what
I am finishing up right now. I have about 80% of the functionality done
(or I hope it is 80% :-). The die-hard lispers will hate me, 'cause I use
a foreign function interface to the C language X libraries, but, hey, it was
there.
Anyway, I hope to have this done by the end of the month (including a
descriptive document much stolen from MIT's Xlib document). If anyone would
care to get an alpha release of the document/software in about 10 days, send
me mail and let me know.
BTW: This low-level interface is being used in conjuction w/ PCL to build an
object oriented X interface, which is no nearly so close to being done, but
someday...
dcm
∂23-Feb-87 1305 RICHER@SUMEX-AIM.STANFORD.EDU Re: X/Common LISP interface
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87 13:04:56 PST
Date: Mon 23 Feb 87 13:03:25-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: X/Common LISP interface
To: dcmartin@INGRES.BERKELEY.EDU
cc: Fahlman@C.CS.CMU.EDU, cl-windows@SAIL.STANFORD.EDU,
RICHER@SUMEX-AIM.STANFORD.EDU
In-Reply-To: <8702230207.AA28193@ingres.Berkeley.EDU>
Message-ID: <12281414254.35.RICHER@SUMEX-AIM.STANFORD.EDU>
I agree with what SCott in a message that may have been addressed to me
personally (I can't remember):
Whether you use a ffi is an implementation issue as long as we agree that
the low-level lisp interface to X is going to be pretty close to XLib in C.
Scott seems to think that is a good idea and apparently David does also.
I'm not 100% committed on that issue, but I agree that the low-level interface
should be defined in such a way that one could choose to either use a ffi,
a native lisp implementation or a combination of both in a way that is
completely transparent to the user of the library. All of the ugliness or
awkwardness that appears in the ffi should obviously be hidden from the
standard interface definition and the user.
If we can agree on this first at least we will start out from the same base,
we can exchange code, etc. Ultimately it will be much more useful if we
can agree on a higher-level interface also, but we need to start somewhere.
mark
-------
∂23-Feb-87 1852 mqb@cive.ri.cmu.edu Re: X/Common LISP interface
Received: from CIVE.RI.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87 18:52:52 PST
Date: Monday, 23 February 1987 21:51:36 EST
From: Monique.Barbanson@cive.ri.cmu.edu
To: "David C. Martin" <dcmartin@ingres.berkeley.edu>
cc: cl-windows@sail.stanford.edu
Subject: Re: X/Common LISP interface
Message-ID: <1987.2.24.2.46.57.Monique.Barbanson@cive.ri.cmu.edu>
In-Reply-To: <8702230207.AA28193@ingres.Berkeley.EDU>
i would be extremely interested in getting such an interface as
i am currently working on a user interface that i'd like to use
with a minimum of modifications on an Explorer and a Sun.
-Monique.
<< Put body of message here. >>
∂24-Feb-87 1733 wanginst!ulowell!grinstei@harvard.harvard.edu Re: X/Common LISP interface
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 24 Feb 87 17:32:32 PST
Received: by seismo.CSS.GOV (5.54/1.14)
id AA19713; Tue, 24 Feb 87 20:32:13 EST
Received: by harvard.harvard.edu; Tue, 24 Feb 87 20:31:56 EST
Received: by wanginst.EDU (4.12/5.8.WangInst)
id AA01274; Tue, 24 Feb 87 08:43:37 est
Posted-Date: Tue, 24 Feb 87 08:22:42 EST
Received: by ulowell.cs.ulowell.edu (5.51/smail2.3/18-Feb-87)
id AA17716; Tue, 24 Feb 87 08:22:42 EST
Date: Tue, 24 Feb 87 08:22:42 EST
From: ulowell.cs.ulowell.edu!wanginst!grinstei@harvard.harvard.edu (Georges Grinstein)
Message-Id: <8702241322.AA17716@ulowell.cs.ulowell.edu>
To: Fahlman@c.cs.cmu.edu, dcmartin@ingres.berkeley.edu
Subject: Re: X/Common LISP interface
Cc: cl-windows@sail.stanford.edu
I am interested in being an alpha site. thanks.
UUCP: wanginst!ulowell!grinstein Dr. Georges Grinstein
ARPA: grinstein@ulowell.CSNET University of Lowell
VOX: +1 617 452 5000 x2681 Lowell MA 01854 USA
∂25-Feb-87 1637 rochester!tropix!dls@seismo.CSS.GOV Re: CW Standard Status
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 25 Feb 87 16:36:17 PST
Received: from rochester.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA15917; Wed, 25 Feb 87 19:36:27 EST
Received: by ur-seneca.arpa id AA08295 (4.12z); Wed, 25 Feb 87 19:25:40 est
Received: by tropix.UUCP (4.12/4.7)
id AA23453; Wed, 25 Feb 87 19:15:10 est
Date: Wed, 25 Feb 87 19:15:10 est
From: rochester!tropix!dls@seismo.CSS.GOV (David L. Snyder )
Message-Id: <8702260015.AA23453@tropix.UUCP>
To: fahlman@c.cs.cmu.edu, cl-windows@sail.stanford.edu
Subject: Re: CW Standard Status
Cc: rochester!ttropix!dls@seismo.CSS.GOV
Fahlman says in reply to a previous message about CL Window Standards...
Someone can correct me if this is wrong, but I believe it is the case
that nobody is currently working on a Common Lisp Window Standard. It
is my own belief that there will never be a single window standard for
all of the Common Lisp world. Such a thing would have to assume such a
low level of functionality that it would be worthless to most of us.
Not every machine running Common Lisp has a 2000x2000 24-plane color
display with real-time animation processor and 6-D 5-button bat (a
flying mouse); some machines still think they are talking to a teletype
or a deck of punched cards. It's hard to imagine any window standard
that can successfully span that kind of range...
I couldn't disagree more with what I understand him to mean. Perhaps
this is because my concept of "window standard" is not standard? I
consider a window standard to:
(1) define a minimum functionality that exists on any
implementation of the standard.
(2) allow for individual vendor to provide supersets of the
minimum functionality.
(3) allow the functionality to be provided in any way that
gets the job done.
Furthermore, I perceive two layers for the window implementation.
The first specifies a bunch of lisp routines, variables, macros, and so on,
that any application can invoke. This bunch of stuff might be exactly
what Xerox D machines provides for building menus and windows,
tracking a mouse, &tc., or it might be IntelliCorp's CommonWindows.
It would *NOT* be anything X-like. The names of these lisp functions,
&tc. would be things like
(CreateWindow x-top-left y-top-left ...),
(CreateMenu name entries ...),
(WindowTitle window newtitle ...),
(DrawObject object line-width coords ...),
and so on.
[I've never hacked Symbolics interfaces, so I can't speak to the o-o
issues.]
The second layer of the window standard is much more controversial,
might just be the "RasterOps on wheels" upon which the first layer is
implemented. What I think Scott is missing here is that these routines
could play on an underlying standard for still lower level cruft, like
X. So, on a Vax they might have similar names to X routines,
and just be foreign calls to X routines written in C. Or the X
routines might (less intelligently but maybe more efficiently) be
written in lisp and call more primitive BitBlt routines. Or Sun/Lucid
might have these routines hook into NewS, even though X can run on top
of NewS, for efficiency or to provide nicer functionality.
The point here is that there are several levels of win. On the one
hand, all the code I run on my Vax will *look* (and run) exactly the
same on my Sun; I'll get similar looking windows, graphics, menus,
&tc. (assuming I stick to the standard, of course). If I move code
from a windowing machine to one that only supports ASR 33 interfaces
that's tough cookies for me. If I use color on one system and move
code to a system that doesn't have it I can't complain about the
standard breaking down.
I win at a lower level too, since all I have to do is implement the X
standard on my particular hardware. For *lots* of hardware that will
have already been done; if it hasn't I'll probably have to do it
anyway to satisfy other applications (assuming it isn't special
purpose hardware).
There's absolutely no reason this window standard business has to be
as intractable as some make it out to be. Agreeing on the top layer
of functionality isn't that hard! There aren't *really* that many
diffences between the existing approaches. And since X is becoming so
ubiquituous, it's the logical choice for a second support layer.
(Although I personally think NewS is superior--Teitelman and Gosling
(I think) deserve a lot of credit for developing the idea of having
the same graphics description language for all display devices.)
Most machines will already have it written in C so you're all done.
The only real problem I forsee is that performance might suffer, but
only experimentation will tell for sure.
David
∂02-Mar-87 2124 WELCH%OSU-20@ohio-state.ARPA X in CL
Received: from OHIO-STATE.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87 21:24:36 PST
Return-Path: <WELCH@OSU-20>
Received: from OSU-20 (osu-20.ARPA) by ohio-state.ARPA (4.12/6.1.OSU-CIS)
id AA04603; Mon, 2 Mar 87 16:35:50 est
Message-Id: <8703022135.AA04603@ohio-state.ARPA>
Date: Mon 2 Mar 87 16:31:15-EST
From: Arun <Welch%OSU-20@ohio-state.ARPA>
Subject: X in CL
To: cl-windows@sail.stanford.edu
It looks like some people are developing Lisp interfaces to X, or in some
cases Lisp implementations of X. For someone starting a new port, it would
be usefull if one didn't have to reinvent the wheel, or get halfway through
a port only to discover that someone else has already done one. So, I'd
like to take a poll to see who has done a port, and if you're willing to
share code. Which machine have you done it on, which implementation of
Lisp if its not a pure-lisp machine, and if you've got PCL hooks into it
would be really usefull information.
...arun
-------
∂09-Mar-87 1201 KASTNER@IBM.COM
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 9 Mar 87 12:01:25 PST
Date: 9 March 1987, 14:42:32 EST
From: "John K. Kastner" <KASTNER@ibm.com>
To: cl-windows@sail.stanford.edu
cc: kastner@ibm.com
Please add me (KASTNER@IBM.COM) to the CL-WINDOWS@SAIL.STANFORD.EDU
mailing list.
Thank you,
John Kastner
∂10-Mar-87 1215 pierce@rd1632 Common Lisp Windows
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Mar 87 12:15:28 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab22682; 10 Mar 87 15:01 EST
Received: from ncr by RELAY.CS.NET id ab18334; 10 Mar 87 14:02 EST
Subject: Common Lisp Windows
To: CL-WINDOWS@SAIL.STANFORD.EDU
From: pierce@rd1632
Date: Tue, 10 Mar 87 13:37:37 -0500 (at ncrlnk.Dayton.NCR.COM)
From: Gene Pierce
Location: NCR CORP. WHQ/5E Dayton, Ohio 45479
To: To whom it may concern
Please add my name to the Common Lisp Windows Discussion list.
Thank You
Gene Pierce
∂10-Mar-87 1221 AKBARI@CS.COLUMBIA.EDU please add me
Received: from CS.COLUMBIA.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 12:20:33 PST
Date: Tue 10 Mar 87 15:19:44-EST
From: John C. Akbari <AKBARI@CS.COLUMBIA.EDU>
Subject: please add me
To: works-request@RUTGERS.RUTGERS.EDU, cl-windows@SAIL.STANFORD.EDU,
common-lisp@SAIL.STANFORD.EDU
Message-ID: <12285338462.45.AKBARI@CS.COLUMBIA.EDU>
to your list.
ad...THANKS...vance!
john c akbari
ARPANET & Internet akbari@CS.COLUMBIA.EDU
BITnet akbari%CS.COLUMBIA.EDU@WISCVM.WISC.EDU
uucp & usenet ...!seismo!columbia!cs!akbari
DECnet akbari@cs
PaperNet 380 riverside drive, no. 7d
new york, new york 10025 usa
SoundNet 212.662.2476
-------
∂12-Mar-87 1405 dcmartin@ingres.Berkeley.EDU X/Common LISP interface
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 12 Mar 87 14:05:34 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
id AA14094; Thu, 12 Mar 87 13:40:35 PST
Date: Thu, 12 Mar 87 13:40:35 PST
From: dcmartin@ingres.Berkeley.EDU (David C. Martin)
Message-Id: <8703122140.AA14094@ingres.Berkeley.EDU>
To: cl-windows@sail.stanford.edu
Subject: X/Common LISP interface
There is now a X/Common LISP interface available for alpha release. You
may acquire it via public ftp from ingres.Berkeley.EDU.
This release currently only works under Extended Common LISP from Franz, Inc.
Please read the README file and send mail to xcl-users-request if you
acquire the software.
dcm
-----
David C. Martin
-----
Computer Science Division
University of California
Berkeley, CA 94720
-----
arpa: dcmartin@ingres.Berkeley.EDU
uucp: {ihnp4,decvax}!ucbvax!dcmartin
at&t: 415/642-9585 (O)
∂21-Mar-87 1733 RICHER@SUMEX-AIM.STANFORD.EDU [gabriel@vaxa.isi.edu (Gabriel Robins): Re: ISI grapher]
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Mar 87 17:32:58 PST
Date: Sat 21 Mar 87 17:33:48-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: [gabriel@vaxa.isi.edu (Gabriel Robins): Re: ISI grapher]
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12288279220.19.RICHER@SUMEX-AIM.STANFORD.EDU>
Some of you may be interested in this grapher package available from ISI.
Please contact Gabriel Robbins, not me, because I cannot help you in any
way. In fact I do not have the package myself yet! I had thoughts of porting
the graphics layer to work under X, but for various reasons I doubt that
will happen. At this point it may pay to get it working under V11 rather
than V10.
---------------
Return-Path: <gabriel@vaxa.isi.edu>
Received: from vaxa.isi.edu by SUMEX-AIM.STANFORD.EDU with TCP; Fri 6 Feb 87 17:45:15-PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA26261; Fri, 6 Feb 87 17:44:04 pst
From: gabriel@vaxa.isi.edu (Gabriel Robins)
Message-Id: <8702070144.AA26261@vaxa.isi.edu>
Date: 6 Feb 1987 1744-PST (Friday)
To: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: ISI grapher
In-Reply-To: Your message of Thu 5 Feb 87 20:30:20-PST.
<12276777021.13.RICHER@SUMEX-AIM.STANFORD.EDU>
Mark,
I am now working at 30% of full-time, but it is exclusively on the ISI
Grapher. I am trying to put out a complete manual for it and really shake the
code down.
I just ported it to Genera version 7, but I don't have the time right now
to port it to HP's; the bottom graphics layer is localized, both logically and
physically, so it should not take more than a few days in any case. I'd love
for your people to do it if you can manage it; I'll give you any advice and
phone consultation you might need.
Feel free to point people in my direction if my package could help them.
I also noticed that several people on the CL-WINDOWS list could benefit from
it. You may want to post a message about it to the list itself. I leave it
up to you. For the record, I enclose a short description of my system.
Gabe
----------------------------------------------------------------------
The ISI Grapher: Its Current State and Its Future
Gabriel Robins
January, 1987
The ISI Grapher is a set of functions that convert an arbitrary graph
structure (or relation) into an equivalent pictorial representation and
displays the resulting diagram. Nodes and edges in the graph become boxes and
lines on the workstation screen, and the user may then interact with the
Grapher in various ways via the mouse and the keyboard.
The fundamental motivation which gave birth to the ISI Grapher is the
observation that graphs are very basic and common structures, and the belief
that the ability to quickly display, manipulate, and browse through graphs may
greatly enhance the productivity of a researcher, both quantitatively and
qualitatively. This seems especially true in knowledge representation and
natural language research.
The ISI Grapher is both powerful and versatile, allowing an
application-builder to easily build other tools on top of it. The ISI NIKL
Browser is an example of one such tool. The salient features of the ISI
Grapher are its portability, speed, versatility, and extensibility. Several
additional applications were already built on top of the ISI Grapher,
providing the ability to graph lists, flavors, packages, divisors, functions,
and Common-Loops classes.
Several basic Grapher operations may be user-controlled via the specification
of alternate functions for performing these tasks. These operations include
the drawing of nodes and edges, the selection of fonts, the determination of
print-names, pretty-printing, and highlighting operations. Standard
definitions are already provided for these operations and are used by default
if the application-builder does not override them by specifying his own funti
ons for performing the same tasks.
The ISI Grapher now spans almost 100 pages of CommonLisp code. The ISI
Grapher manual is currently 55 pages long, and it is two-thirds finished. The
manual describes the general ideas, the interface, the application-builder's
back-end, the algorithms, the implementation, and the data structures. Until
the full manual is ready, a temporary less detailed document is available upon
request. Several minor bugs still plague the code, but are being fixed
currently. Further testing and bullet-proofing is planned. The ISI Grapher
presently runs on both Symbolics (6 & 7) and TI Explorer workstations.
The ISI Grapher has already drawn considerable interest; external parties
that have requested the code include Teknowledge, BBN, Inference, & JPL.
It is projected that the ISI Grapher would attain production-quality by
the beginning of the summer.
We welcome comments and suggestions; please direct all feedback to
gabriel at vaxa.isi.edu and lmiller at venera.isi.edu.
----------------------------------------------------------------------
-------
∂02-Apr-87 1533 MMcM@STONY-BROOK.SCRC.Symbolics.COM Window systems standardization
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Apr 87 15:33:03 PST
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 108011; Thu 2-Apr-87 18:33:01 EST
Date: Thu, 2 Apr 87 18:33 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Window systems standardization
To: cl-windows@sail.stanford.edu
Message-ID: <870402183306.7.MMCM@OWL.SCRC.Symbolics.COM>
Any window system standard should be carefully designed to be properly
layered. Naturally, application programmers will want to use the
uppermost layers whenever possible. By doing so, not only do they
increase their productivity by achieving a higher level of abstraction,
but they also insulate themselves from differences in the lower levels.
On the negative side, these upper layers are most often proprietary and
most dependent on the host operating system and window management
paradigms. For this reason, it is vital that each layer be well
organized and that as many as possible be standardized to as great a
degree as possible.
Here are some of the layers which I recognize:
Level 0. A standardized set of lowest level graphics (that is imaging)
subprimitives, upon which a native implementation of a virtual console
layer such as X could be based. This would be useful both for lisp
machines per se and for environments in which there was not an existing
X implementation in some other language as part of the operating system.
Such an implementation could even be public domain, or copyright MIT.
These functions would provide more or less direct access to a frame
buffer.
Level 1. A standardized set of functions supporting a LISP
value-oriented X library, using standard Common Lisp calling sequences.
This is similar to the XLib integration of X into the C programming
environment and calling sequence. Note that the existence of X on the
machine already implemented in C does not require a foreign function
interface to the XLib library. Because of the nature of the X protocol,
the LISP X library could just as well interface to the local X server
via the same shared memory (or whatever) primitives that the XLib
library itself did. Any incompatibility of calling sequences need not
be an issue. X itself is in no way C specific. Once again, there could
be a standard implementation in LISP of this for byte-stream access to
servers, using just host specific network/memory buffer primitives.
Separately, there could be a implementation that actually did a foreign
function call to an X library in some other language. Or there could be
yet another implementation that directly called into existing window
system primitives, assuming they managed to correctly model X window
concepts.
It should be noted that
a. There is no guarantee that the standard WRITE-STRING or READ-CHAR
from Steele will accept anything returned by this layer as their
optional stream argument.
b. The application programmer visible window abstraction will often be
an encapsulation of several primitive X windows to achieve higher level
effects, such as scrolling or complex margin decoration.
c. While it might be possible to implement a simple graphics hack like
QIX using this layer, there wouldn't really be any guarantees of
keyboard input access or synchronization.
Level 2. An extension of the Common Lisp stream standard, based on the
emerging Common Lisp Object System standard. The primitive I/O
operations, such as READ-CHAR, WRITE-CHAR, WRITE-STRING, FORCE-OUTPUT,
and FINISH-OUTPUT are made generic. As much as possible, this layer
tries to avoid issues related to the window management paradigm of a
particular host, so that the program is still portable without that
window manager as an included library.
Furthermore, the implementation based on the X virtual console
specification need not be the only version of this standard. There
could even be different implementations of different interface
paradigms, all based on X. It would be possible to implement it on top
of another low level windowing standard, such as NewS. More critically,
it might be possible to implement it on top of the larger existing Lisp
window systems, without necessitating wholesale replacement of console
substrate. Such replacement, even when it is planned for the future, is
by no means a short term possibility for most vendors with large
installed bases.
This layer would provide those facilities necessary for construction of
things like a lisp listener window. The interaction style would not
necessarily be the same on all machines, but in general terms the
program would have
a. A READ, EVAL, PRINT command loop program, for which most but not all
the pieces are included in the Steele manual already.
b. An input editor, that is a program that takes keystrokes and gives a
reliable stream of editing input. This is the stream that READ talks
to. Such an editing program's interface would be part of this standard
layer, although particular editing paradigms would be reserved to system
interface designer's whims.
c. An asynchronous monitor of keystrokes if lisp is to be interruptible.
d. An output exception handler that causes something worthwhile to
happen when more output than the initial size of the window has been
exceeded. There are several possibilities for actions to take when this
occurs. Control of which one any particular window has could be
standardized, even if there were no guarantee that all systems provided
all possibilities.
This layer is the approximately equivalent to the specification given by
IntelliCorp's Common Windows.
Level 3. An application programmer oriented graphics output package.
Again, this is a class-based extension of the stream protocol.
Implementations would naturally be provided
a. On top of the X based window standard (via access through the window
object to the core windows that supported the primitive graphical
imaging output).
b. For LaserWriters and other similar high quality output devices,
based on a page layout standard like PostScript or InterPress, and not
on X.
c. On top of other window systems, such as NewS or Zetalisp sheets, if
desired.
This layer would provide necessary application programmer interfaces
that might not be supported by the core. Such as,
a. Coordinate system transformations.
b. Ratio and float coordinates.
c. Higher level shapes, like ovals, ellipses, or cubic splines.
d. Scaled text.
e. Advanced color modeling, including perhaps anti-aliasing.
This level is object oriented in the sense that object oriented
programming techniques are applied to give device independence. The
graphical shapes and any hierarchy that they might form are not objects
defined by this level. This is because there is little point in making
them be objects until one begins to need to control their
interrelationship and mutual constraining. All you gain is saving on
function names. Such higher level graphics, such as might naturally be
part of the substrate for the picture editor or design system, is a
layer yet higher still. The graphical output functions in this layer do
obey what might loosely be construed as object orientation in that the
options that control the texture of the geometrical shapes are specified
in a uniform way for different shapes.
In other words, the functions here provide for drawing of shapes,
a. Circle
b. Triangle
c. Polygon
and generic control of the imaging of the mathematical shape,
a. stroking vs. filling
b. stroke thickness
c. stipple patterns and colors
and so on in a standard way.
Level 4. Application programmer access to the window manager. This is
naturally going to be somewhat host specific, so I don't lay much hope
in standardizing it at this point. Different systems with different
window managers have their vocally inflexible adherents.
Level 5. A full User Interface Management System. Since there is very
little general acceptance of any interface paradigm, either from the
user or programmer side, this is not likely to be standard either.
While these last two layers are not standard, it is possible for them to
be portable, given that they are written exclusively using the lower
layers, which are presumably designed with that aim in mind. Thus even
if an application locks into a particular interface paradigm and/or
toolkit, it still has some chance for portability, if that is a concern.
Moreover, even though the interface paradigms cannot be standardized at
this point, a number of higher level simple interface ideas might be
identified and standard function interfaces specified for them. For
instance, there could be a function that popped up a menu given an
association list of choices. How the user actually did the selection
from the menu and where it appeared on the console would be up the
system.
∂03-Apr-87 0603 @ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU CLX proposal: cover message
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Apr 87 06:03:11 PST
Received: from KILLINGTON.LCS.MIT.EDU (KILLINGTON.LCS.MIT.EDU) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 40113; 3 Apr 87 09:04:55 EST
Date: Fri, 3 Apr 87 09:05 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX proposal: cover message
To: cl-windows@SAIL.STANFORD.EDU
File-References: LCS|MILO:/pub/clx.lisp
Message-ID: <870403090502.5.RWS@KILLINGTON.LCS.MIT.EDU>
In a follow-on message, I will send out a proposal for a standard Common
Lisp interface to X Version 11, for public review. The proposal is also
available via anonymous ftp as /pub/clx.lisp on milo.lcs.mit.edu. In
addition to myself, the contributors are Mike McMahon (Symbolics),
Dan Cerys (Texas Instruments), John Wroclawski (MIT), and Rich Zippel
(Symbolics).
A message about this proposal is also being sent to the xpert mailing
list, but we expect the primary discussion will take place on the
cl-windows list. If you need to communicate "directly" with us for some
reason, please send mail to clx@zermatt.lcs.mit.edu.
The interface is intended to provide functionality equivalent to that of
the Xlib interface for C; that is, it is a relatively low-level interface,
"close" to the raw protocol (Level 1 in Mike McMahon's recent layers
message). The interface has been designed by working directly from the
protocol documentation, and trying to provide a "natural" Lisp interface,
rather than by trying to mimic the precise routines in the C Xlib.
The proposal contains very little "documentation". We assume that anyone
seriously interested in reviewing the proposal will have read the protocol
document and/or the C Xlib document. From either of those documents, the
Lisp interface should be fairly obvious, and we have sprinkled a few
comments in various places. The proposal is based on the expected "Beta
Test" version of the protocol; as such, it contains several changes from
the "Alpha Test" version, most of which should be clear to the reader.
Our intention is to provide a (public) native Common Lisp implementation
of the interface, once the design has gone through a public review. We
would like to "close" the review on May 15, so that implementation can get
underway. Anyone wishing to contribute to this effort should send mail to
clx@zermatt.lcs.mit.edu. We have no intention of providing an
implementation based on a foreign-function interface to the C Xlib,
although we do not wish the design to preclude such an implementation.
It was our desire to define an interface that could be implemented
reasonably in Lisps on conventional hardware, without sacrificing user
programming convenience, but we have very little experience with, or
detailed knowledge of, such Lisp implementations. Feedback with respect
to performance and feasibility is most welcome.
It is our intention that relatively little programming will take place
using the Xlib facilities directly. Instead (as indicated in Mike
McMahon's recent message), it is hoped that higher level graphics and
toolkit facilities can be put in place for most programmers to use, and
further that such graphics and toolkit facilities provide sufficient
abstraction as to be relatively independent of a particular virtual
console protocol like X. Tentative proposals and discussion along these
lines should be forthcoming in the near future.
∂03-Apr-87 0606 @ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU CLX: a proposal
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Apr 87 06:05:45 PST
Received: from KILLINGTON.LCS.MIT.EDU (KILLINGTON.LCS.MIT.EDU) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 40114; 3 Apr 87 09:06:56 EST
Date: Fri, 3 Apr 87 09:06 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX: a proposal
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870403090652.6.RWS@KILLINGTON.LCS.MIT.EDU>
;;; -*- Mode: LISP; Syntax: Common-lisp; Package: (XLIB (CL)); Base: 10; Lowercase: Yes -*-
; Author:
; Robert W. Scheifler
; Laboratory for Computer Science
; 545 Technology Square, Room 418
; Cambridge, MA 02139
; rws@zermatt.lcs.mit.edu
; Contributors:
; Mike McMahon, Symbolics
; Dan Cerys, Texas Instruments
; John Wroclawski, MIT
; Rich Zippel, Symbolics
; Note: various perversions of the CL type system are used below.
; Examples: (list elt-type) (sequence elt-type)
(proclaim '(declaration arglist values))
; Note: if you have read the Version 11 protocol document or C Xlib manual, most of
; the relationships should be fairly obvious. We have no intention of writing yet
; another moby document for this interface.
; Types employed: display, window, pixmap, cursor, font, gc, colormap, color.
; These types are defined solely by a functional interface; we do not specify whether
; they are implemented as structures or flavors or ... Although functions below are
; written using DEFUN, this is not an implementation requirement (although it is a
; requirement that they be functions as opposed to macros or special forms). It is
; unclear whether with-slots in the Common Lisp Object System must work on them.
; Windows, pixmaps, cursors, fonts, gcs, and colormaps are all represented as
; compound objects, rather than as integer resource-ids.
; This allows applications to deal with multiple displays without having
; an explicit display argument in every function. Every function uses the
; display object indicated by the first argument that is or contains a display;
; it is an error if arguments contain different displays, and predictable results
; are not guaranteed.
; Each of window, pixmap, cursor, font, gc, and colormap have the functions:
(defun make-<mumble> (display resource-id)
; This function should almost never be called by applications, except in handling events.
; To minimize consing in some implementations, this may use a cache in the display.
; Make-gc creates with :cache :off.
(declare (type display display)
(type integer resource-id)
(values <mumble>)))
(defun <mumble>-display (<mumble>)
(declare (type <mumble> <mumble>)
(values display)))
(defun <mumble>-id (<mumble>)
(declare (type <mumble> <mumble>)
(values integer)))
(defun <mumble>-equal (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)))
(defun <mumble>-p (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)
(values boolean)))
; The following functions are provided by color objects:
; The intention is that IHS and YIQ and CYM interfaces will also exist.
; Note that we are explicitly using a different spectrum representation
; than what is actually transmitted in the protocol.
(defun make-color (&key red green blue &allow-other-keys) ; for expansion
(declare (type (number 0 1) red green blue)
(values color)))
(defun color-rgb (color)
(declare (type color color)
(values red green blue)))
(defun color-red (color)
; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-green (color)
; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-blue (color)
; setf'able
(declare (type color color)
(values (number 0 1))))
(deftype resource-id () 'integer)
(deftype drawable () '(or window pixmap))
; Atoms are accepted as strings or symbols, and are always returned as keywords.
; Protocol-level integer atom ids are hidden, using a cache in the display object.
(deftype xatom () '(or string symbol))
(deftype stringable () '(or string symbol))
(deftype fontable () '(or stringable font))
; Nil stands for CurrentTime.
(deftype timestamp () '(or null integer))
(deftype bit-gravity () '(member :forget :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype win-gravity () '(member :unmap :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype grab-status () '(member :success :already-grabbed :invalid-time :not-viewable))
(deftype boolean () '(or null (not null)))
; An association list.
(deftype alist (key-type-and-name datum-type-and-name) 'list)
; A sequence, containing zero or more repetitions of the given elements,
; with the elements expressed as (type name).
(deftype repeat-seq (&rest elts) 'sequence)
(deftype point-seq () '(repeat-seq (integer x) (integer y)))
(deftype seg-seq () '(repeat-seq (integer x1) (integer y1) (integer x2) (integer y2)))
(deftype rect-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)))
; Note that we are explicitly using a different angle representation than what
; is actually transmitted in the protocol.
(deftype angle () `(number ,(* -2 pi) ,(* 2 pi)))
(deftype arc-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)
(angle angle1) (angle angle2)))
(deftype event-mask-class ()
'(member :key-press :key-release :owner-grab-button :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :exposure :visibility-change
:structure-notify :resize-redirect :substructure-notify :substructure-redirect
:focus-change :property-change :colormap-change :keymap-state))
(deftype event-mask ()
'(or integer (list event-mask-class)))
(deftype pointer-event-mask-class ()
'(member :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :keymap-state))
(deftype pointer-event-mask ()
'(or integer (list pointer-event-mask-class)))
(deftype device-event-mask-class ()
'(member :key-press :key-release :button-press :button-release :pointer-motion
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion))
(deftype device-event-mask ()
'(or integer (list device-event-mask-class)))
(deftype modifier-key ()
'(member :shift :caps-lock :control :mod-1 :mod-2 :mod-3 :mod-4 :mod-5))
(deftype modifier-mask ()
'(or (member :any) integer (list modifier-key)))
(deftype state-mask-key ()
'(or modifier-key (member :button-1 :button-2 :button-3 :button-4 :button-5)))
(deftype gc-key ()
'(member :function :plane-mask :foreground :background
:line-width :line-style :cap-style :join-style :fill-style :fill-rule
:arc-mode :tile :stipple :ts-x :ts-y :font :subwindow-mode
:graphics-exposures :clip-x :clip-y :clip-mask :clip-ordering
:dash-offset :dashes))
(deftype event-key ()
'(member :key-press :key-release :button-press :button-release :motion-notify
:enter-notify :leave-notify :focus-in :focus-out :keymap-notify
:exposure :graphics-exposure :no-exposure :visibility-notify
:create-notify :destroy-notify :unmap-notify :map-notify :map-request
:reparent-notify :configure-notify :gravity-notify :resize-request
:configure-request :circulate-notify :circulate-request :property-notify
:selection-clear :selection-request :selection-notify
:colormap-notify :client-message))
(deftype error-key ()
'(member :access :alloc :atom :colormap :cursor :drawable :font :gc :id-choice
:illegal-request :implementation :length :match :name :pixmap :property
:value :window))
(deftype draw-direction ()
'(member :left-to-right :right-to-left))
(defstruct pixmap-format
(depth <unspec> :type integer)
(bits-per-pixel <unspec> :type (member 4 8 16 32))
(scanline-pad <unspec> :type (member 8 16 32)))
(defstruct image-info
(image-lsb-first-p <unspec> :type boolean)
(bitmap-scanline-unit <unspec> :type (member 8 16 32))
(bitmap-scanline-pad <unspec> :type (member 8 16 32))
(bitmap-lsb-first-p <unspec> :type boolean)
(pixmap-formats <unspec> :type (list pixmap-format)))
(defstruct visual-info
(id <unspec> :type integer)
(class <unspec> :type (member :static-gray :static-color :true-color
:gray-scale :pseudo-color :direct-color))
(red-mask <unspec> :type integer)
(green-mask <unspec> :type integer)
(blue-mask <unspec> :type integer)
(bits-per-rgb <unspec> :type integer)
(colormap-entries <unspec> :type integer))
(defstruct screen
(root <unspec> :type window)
(device <unspec> :type integer)
(width <unspec> :type integer)
(height <unspec> :type integer)
(width-in-millimeters <unspec> :type integer)
(height-in-millimeters <unspec> :type integer)
(depths <unspec> :type (alist (integer depth) ((list visual-info) visuals)))
(root-depth <unspec> :type integer)
(root-visual <unspec> :type integer)
(default-colormap <unspec> :type colormap)
(white-pixel <unspec> :type integer)
(black-pixel <unspec> :type integer)
(min-installed-maps <unspec> :type integer)
(max-installed-maps <unspec> :type integer)
(backing-stores <unspec> :type (member :never :when-mapped :always))
(save-unders-p <unspec> :type boolean)
(event-mask-at-open <unspec> :type integer))
; To allow efficient storage representations, the type char-info is not
; required to be a structure.
(defun char-left-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-right-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-width (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-ascent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-descent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-attributes (char-info)
(declare (type char-info char-info)
(values integer)))
; alternating keywords and integers
(deftype font-props () 'list)
(defstruct font-info
(name <unspec> :type string)
(direction <unspec> :type draw-direction)
(min-char <unspec> :type integer)
(max-char <unspec> :type integer)
(min-byte1 <unspec> :type integer)
(max-byte1 <unspec> :type integer)
(min-byte2 <unspec> :type integer)
(max-byte2 <unspec> :type integer)
(all-chars-exist-p <unspec> :type boolean)
(min-bounds <unspec> :type char-info)
(max-bounds <unspec> :type char-info)
(ascent <unspec> :type integer)
(descent <unspec> :type integer)
(properties <unspec> :type font-props))
(defun open-display (host &key (display 0) protocol)
; A string must be acceptable as a host, but otherwise the possible types
; for host and protocol are not constrained, and will likely be very
; system dependent. The default protocol is system specific. Authorization,
; if any, is assumed to come from the environment somehow.
(declare (type integer display)
(values display)))
(defun display-protocol-version (display)
(declare (type display display)
(values major minor)))
(defun display-vendor-id (display)
(declare (type display display)
(values name release)))
(defun display-image-info (display)
(declare (type display display)
(values image-info)))
(defun display-roots (display)
(declare (type display display)
(values (list screen))))
(defun display-keyboard (display)
(declare (type display display)
(values integer)))
(defun display-pointer (display)
(declare (type display display)
(values integer)))
(defun display-motion-buffer-size (display)
(declare (type display display)
(values integer)))
(defun display-max-request-length (display)
(declare (type display display)
(values integer)))
(defun close-display (display)
(declare (type display display)))
(defun display-error-handler (display)
(declare (type display display)
(values handler)))
(defsetf display-error-handler (display) (handler)
; All errors (synchronous and asynchronous) are processed by calling
; an error handler in the display. If handler is a function, it is
; called with the error-key as its second argument; if handler is
; an array it is expected to contain handler functions specific to
; each error; the error code is used to index the array, fetching the
; appropriate handler. Any results returned by the handler are ignored;
; it is assumed the handler either takes care of the error completely,
; or else signals. For all core errors, additional keyword/value argument
; pairs are:
; :major integer
; :minor integer
; :sequence integer
; :current-sequence integer
; For :colormap, :cursor, :drawable, :font, :gc, :id-choice, :pixmap, and :window
; errors another pair is:
; :resource-id integer
; For :atom errors, another pair is:
; :atom-id integer
; For :value errors, another pair is:
; :value integer
(declare (type display display)
(type (or (array (function (display &rest key-vals)))
(function (display error-key &rest key-vals)))
handler)))
(defun default-error-handler (display error-key &rest key-vals)
; The default display-error-handler.
; It signals the conditions listed below.
)
(defmacro define-condition (name base &body items)
; just a place-holder here for the real thing
)
(define-condition request-error error
display
major
minor
sequence
current-sequence)
(define-condition resource-error request-error
resource-id)
(define-condition access-error request-error)
(define-condition alloc-error request-error)
(define-condition atom-error request-error
atom-id)
(define-condition colormap-error resource-error)
(define-condition cursor-error resource-error)
(define-condition drawable-error resource-error)
(define-condition font-error resource-error)
(define-condition gc-error resource-error)
(define-condition id-choice-error resource-error)
(define-condition illegal-request-error request-error)
(define-condition implementation-error request-error)
(define-condition length-error request-error)
(define-condition match-error request-error)
(define-condition name-error request-error)
(define-condition pixmap-error resource-error)
(define-condition property-error request-error)
(define-condition value-error request-error
value)
(define-condition window-error resource-error)
(defmacro with-display ((display) &body body)
; This macro is for use in a multi-process environment.
; It provides exclusive access to the local display object for request generation
; and reply processing. Except where noted, all of the routines below should be
; thought of as containing an implicit with-display, so that correct synchronization
; is always provided at the interface level on a per-call basis. Nested uses of this
; macro will work correctly. This macro does not prevent concurrent event processing;
; see with-event-queue.
)
(defun display-force-output (display)
; Output is normally buffered, this forces any buffered output.
(declare (type display display)))
(defun display-finish-output (display)
; Forces output, then causes a round-trip to ensure that all possible
; errors and events have been received.
(declare (type display display)))
(defun display-after-function (display)
; setf'able (setf form uses with-display)
; If defined, called after every protocol request is generated, even those
; inside multiply nested with-display's, but never called from inside the
; after-function itself.
; Default value is nil.
; Can be set, for example, to #'display-force-output or #'display-finish-output.
(declare (type display display)
(values (or null (function (display))))))
(defun create-window (&key parent x y width height (depth 0) (border-width 0)
(class :copy) (visual :copy)
background border
bit-gravity win-gravity
backing-store backing-bit-planes backing-pixel save-under
event-mask do-not-propagate-mask override-redirect
colormap cursor)
; Display is obtained from parent. Only non-nil attributes are passed on in
; the request: the function makes no assumptions about what the actual protocol
; defaults are. Width and height are the inside size, excluding border.
(declare (type window parent)
(type integer x y width height depth border-width)
(type (member :copy :input-output :input-only) class)
(type (or (member :copy) visual) visual)
(type (or null (member :none :parent-relative) integer pixmap) background)
(type (or null (member :copy) integer pixmap) border)
(type (or null bit-gravity) bit-gravity)
(type (or null win-gravity) win-gravity)
(type (or null (member :not-useful :when-mapped :always) backing-store))
(type (or null integer) backing-bit-planes backing-pixel)
(type (or null event-mask) event-mask)
(type (or null device-event-mask) do-not-propagate-mask)
(type (or null (member :on :off)) save-under override-redirect)
(type (or null (member :copy) colormap) colormap)
(type (or null (member :none) cursor) cursor)
(values window)))
(defun change-window-attributes (window &key
background border
bit-gravity win-gravity
backing-store backing-bit-planes backing-pixel save-under
event-mask do-not-propagate-mask override-redirect
colormap cursor)
; Should there be individual setfs for these as well?
; Rename this change-window and add configure-window args, and drop configure-window?
(declare (type window window)
(type (or null (member :none :parent-relative) integer pixmap) background)
(type (or null (member :copy) integer pixmap) border)
(type (or null bit-gravity) bit-gravity)
(type (or null win-gravity) win-gravity)
(type (or null (member :not-useful :when-mapped :always)) backing-store)
(type (or null integer) backing-bit-planes backing-pixel)
(type (or null event-mask) event-mask)
(type (or null device-event-mask) do-not-propagate-mask)
(type (or null (member :on :off)) save-under override-redirect)
(type (or null (member :copy) colormap) colormap)
(type (or null (member :none) cursor) cursor)))
(defun window-attributes (window)
; Should there be individual accessors as well?
; Order of key-value pairs is not specified.
(declare (type window window)
(values :visual integer
:class (member :input-output :input-only)
:bit-gravity bit-gravity
:win-gravity win-gravity
:backing-store (member :not-useful :when-mapped :always)
:backing-bit-planes integer
:backing-pixel integer
:save-under (member :on :off)
:colormap (or null colormap)
:colormap-installed-p boolean
:map-state (member :unmapped :unviewable :viewable)
:all-event-masks integer
:event-mask integer
:do-not-propagate-mask integer
:override-redirect (member :on :off))))
(defun destroy-window (window)
(declare (type window window)))
(defun destroy-subwindows (window)
(declare (type window window)))
(defun save-set-insert (window)
(declare (type window window)))
(defun save-set-delete (window)
(declare (type window window)))
(defun reparent-window (window parent x y)
(declare (type window window parent)
(type integer x y)))
(defun map-window (window)
(declare (type window window)))
(defun map-subwindows (window)
(declare (type window window)))
(defun unmap-window (window)
(declare (type window window)))
(defun unmap-subwindows (window)
(declare (type window window)))
(defun configure-window (window &key x y width height border-width stack-mode sibling)
; Width and height are the inside size, excluding border.
(declare (type window window)
(type (or null integer) x y width height border-width)
(type (or null (member :above :below :top-if :bottom-if :opposite)) stack-mode)
(type (or null window) sibling)))
(defun circulate-window (window &key up-p)
(declare (type window window)
(type boolean up-p)))
(defun drawable-geometry (drawable)
; Width and height are the inside size, excluding border.
; Order of key-value pairs is not specified.
(declare (type drawable drawable)
(values :root window
:depth integer
:x integer
:y integer
:width integer
:height integer
:border-width integer)))
(defun drawable-size (drawable)
; Width and height are the inside size, excluding border.
(declare (type drawable drawable)
(values width height border-width)))
(defun drawable-rectangle (drawable)
; Width and height are the outside size, including border.
(declare (type drawable drawable)
(values x y width height border-width)))
(defun query-tree (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence window) parent root)))
(defun store-property (window property data type format
&key (mode :replace) (start 0) end transform)
; Start and end affect sub-sequence extracted from data.
; Transform is applied to each extracted element.
(declare (type window window)
(type xatom property type)
(type (member 8 16 32) format)
(type sequence data)
(type (member :replace :prepend :append) mode)
(type (or null integer) start end)
(type (or null (function (t) integer)) transform)))
(defun delete-property (window property)
(declare (type window window)
(type xatom property)))
(defun get-property (window property
&key type (start 0) end delete-p (result-type 'list) transform)
; Transform is applied to each integer retrieved.
(declare (type window window)
(type xatom property)
(type (or null xatom) type)
(type (or null integer) start end)
(type boolean delete-p)
(type type result-type)
(type (or null (function (integer) t)) transform)
(values data type format bytes-after)))
(defun rotate-properties (window properties &optional (delta 1))
; Postive rotates left, negative rotates right (opposite of actual protocol request).
(declare (type window window)
(type (sequence xatom) properties)
(type integer delta)))
(defun list-properties (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence satom))))
(defun set-selection-owner (display selection owner &key time)
(declare (type display display)
(type xatom selection)
(type (or null window) owner)
(type timestamp time)))
(defun selection-owner (display selection)
(declare (type display display)
(type xatom selection)
(values (or null window))))
(defun convert-selection (selection type requestor &key property time)
(declare (type xatom selection type)
(type window requestor)
(type (or null xatom) property)
(type timestamp time)))
(defun send-event (window event-key event-mask &rest args
&key propagate-p &allow-other-keys)
; Additional arguments depend on event-key, and are as in next-event.
; Should this take resource-ids or resource objects or both in other-keys?
(declare (type window window)
(type event-key event-key)
(type event-mask event-mask)
(type boolean propagate-p)))
(defun send-event-to-pointer-window (display event-key event-mask &rest args
&key propagate-p &allow-other-keys)
; Additional arguments depend on event-key, and are as in next-event.
; Should this take resource-ids or resource objects or both in other-keys?
(declare (type display display)
(type event-key event-key)
(type event-mask event-mask)
(type boolean propagate-p)))
(defun send-event-to-input-focus (display event-key event-mask &rest args
&key propagate-p &allow-other-keys)
; Additional arguments depend on event-key, and are as in next-event.
; Should this take resource-ids or resource objects or both in other-keys?
(declare (type display display)
(type event-key event-key)
(type event-mask event-mask)
(type boolean propagate-p)))
(defun grab-pointer (window event-mask
&key owner-p sync-pointer-p sync-keyboard-p confine-to cursor time)
(declare (type window window)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)
(type timestamp time)
(values grab-status)))
(defun ungrab-pointer (&key time)
(declare (type timestamp time)))
(defmacro with-pointer-grabbed
((window event-mask
&key owner-p sync-pointer-p sync-keyboard-p confine-to cursor time)
&body body)
; Blocks and retries until :success or :invalid-time.
; The body is not executed on :invalid-time.
; The body is not surrounded by a with-display.
)
(defun grab-button (window button event-mask
&key (modifiers 0)
owner-p sync-pointer-p sync-keyboard-p confine-to cursor)
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)))
(defun ungrab-button (window button &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)))
(defun change-active-pointer-grab (display event-mask &key cursor time)
(declare (type display display)
(type pointer-event-mask event-mask)
(type (or null cursor) cursor)
(type timestamp time)))
(defun grab-keyboard (window &key owner-p sync-pointer-p sync-keyboard-p time)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type timestamp time)
(values grab-status)))
(defun ungrab-keyboard (display &key time)
(declare (type display display)
(type timestamp time)))
(defmacro with-keyboard-grabbed ((window &key owner-p sync-pointer-p sync-keyboard-p time)
&body body)
; Blocks and retries until :success or :invalid-time.
; The body is not executed on :invalid-time.
; The body is not surrounded by a with-display.
)
(defun grab-key (window key &key (modifiers 0) owner-p sync-pointer-p sync-keyboard-p)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun ungrab-key (window key &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun allow-events (display mode &key time)
(declare (type display display)
(type (member :async-pointer :sync-pointer :async-keyboard :sync-keyboard :replay)
mode)
(type timestamp time)))
(defun grab-server (display)
(declare (type display display)))
(defun ungrab-server (display)
(declare (type display display)))
(defmacro with-server-grabbed ((display) &body body)
; The body is not surrounded by a with-display.
)
(defun query-pointer (window)
; Order of key-value pairs is not specified.
(declare (type window window)
(values :x integer
:y integer
:mask integer
:root window
:child (or null window)
:same-screen-p boolean
:root-x integer
:root-y integer)))
(defun motion-events (window &key start stop (result-type 'list))
(declare (type window window)
(type timestamp start stop)
(type type result-type)
(values (repeat-seq (integer x) (integer y) (timestamp time)))))
(defun translate-coordinates (src src-x src-y dst)
(declare (type window src)
(type integer src-x src-y)
(type window dst)
(values dst-x dst-y child)))
(defun warp-pointer (dst dst-x dst-y)
(declare (type window dst)
(type integer dst-x dst-y)))
(defun conditional-warp-pointer (dst dst-x dst-y src src-x src-y
&optional src-width src-height)
; Passing in a zero src-width or src-height is a no-op.
; A null src-width or src-height translates into a zero value in the protocol request.
(declare (type window dst src)
(type integer dst-x dst-y src-x src-y)
(type (or null integer) src-width src-height)))
(defun set-input-focus (display focus revert-to &key time)
(declare (type display display)
(type (or (member :none :pointer-root) window) focus)
(type (member :none :parent :pointer-root) revert-to)
(type timestamp time)))
(defun input-focus (display)
(declare (type display display)
(values focus revert-to)))
(defun query-keymap (display)
(declare (type display display)
(values (bit-vector 256))))
(defun open-font (display name)
; Font objects may be cached and reference counted locally within the display object.
; Protocol QueryFont request happens on-demand under the covers.
; This might not execute a with-display if the font is cached.
(declare (type display display)
(type stringable name)
(values font)))
(defun font-font-info (font)
(declare (type font font)
(values font-info)))
; For each component (<name> <unspec> :type <type>) of font-info,
; there is a corresponding function:
(defun font-<name> (font)
(declare (type font font)
(values <type>)))
(defun font-property (font name)
(declare (type font font)
(type keyword name)
(values (or null integer))))
(defun font-char-infos (font)
(declare (type font font)
(values (array char-info))))
(defun font-char-info (font char)
(declare (type font font)
(type integer char)
(values (or null char-info))))
(defun font-char16-info (font first-byte second-byte)
(declare (type font font)
(type integer first-byte second-byte)
(values (or null char-info))))
(defun close-font (font)
; This might not generate a protocol request if the font is reference counted locally.
(declare (type font font)))
(defun text-width (font string &key (cache-p t))
; If no font info is cached locally, and cache-p is nil, this uses the protocol request.
; Otherwise, the font info is obtained if necessary, and then the result is computed
; locally.
(declare (type (or font gc) font)
(type string string)
(values integer)))
(defun text-extents (font string &key (cache-p t))
; If no font info is cached locally, and cache-p is nil, this uses the protocol request.
; Otherwise, the font info is obtained if necessary, and then the result is computed
; locally.
; Order of key-value pairs is not specified.
(declare (type (or font gc) font)
(type string string)
(values :direction draw-direction
:font-ascent integer
:font-descent integer
:ascent integer
:descent integer
:width integer
:left integer
:right integer)))
(defun matching-fonts (display pattern &key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence string))))
(defun matching-fonts-and-properties (display pattern
&key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence font-info))))
(defun font-path (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence (or string pathname)))))
(defsetf font-path (display) (paths)
(declare (type display display)
(type (sequence (or string pathname)) paths)))
(defun create-pixmap (&key width height depth drawable)
(declare (type integer width height depth)
(type drawable drawable)
(values pixmap)))
(defun free-pixmap (pixmap)
(declare (type pixmap pixmap)))
(defun create-gc (&key drawable function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
graphics-exposures clip-x clip-y clip-mask clip-ordering
dash-offset dashes
(cache :write-back))
; Only non-nil components are passed on in the request, but for effective caching
; assumptions have to be made about what the actual protocol defaults are.
; Note: use of stringable as font will cause an implicit open-font.
; Note: papers over protocol SetClipRectangles and SetDashes special cases.
; GC state is normally cached locally. Changing a GC component will have no effect
; if the new value matches the cached value. In :write-back mode, changes are not
; sent over the protocol until required by a local operation. In :write-through
; and :off modes, changes are sent immediately. In :off mode, state is not shadowed
; locally.
; Should there be accessors?
(declare (type drawable drawable)
(type (or null boole-constant) function)
(type (or null integer) plane-mask foreground background line-width
ts-x ts-y clip-x clip-y dash-offset)
(type (or null (member :solid :dash :double-dash)) line-style)
(type (or null (member :not-last :butt :round :projecting)) cap-style)
(type (or null (member :miter :round :bevel)) join-style)
(type (or null (member :solid :tiled :opaque-stippled :stippled)) fill-style)
(type (or null (member :even-odd :winding)) fill-rule)
(type (or null (member :chord :pie-slice)) arc-mode)
(type (or null pixmap) tile stipple)
(type (or null fontable) font)
(type (or null (member :clip-by-children :include-inferiors)) subwindow-mode)
(type (or null (member :on :off)) graphics-exposures)
(type (or null (member :none) pixmap rect-seq) clip-mask)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or null integer (sequence integer)) dashes)
(type (member :off :write-back :write-through) cache)
(values gc)))
(defun change-gc (gc &key function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
graphics-exposures clip-x clip-y clip-mask clip-ordering
dash-offset dashes
cache)
; Note: papers over protocol SetClipRectangles and SetDashes special cases.
; Should there be individual setfs?
(declare (type gc gc)
(type (or null boole-constant) function)
(type (or null integer) plane-mask foreground background line-width
ts-x ts-y clip-x clip-y dash-offset)
(type (or null (member :solid :dash :double-dash)) line-style)
(type (or null (member :not-last :butt :round :projecting)) cap-style)
(type (or null (member :miter :round :bevel)) join-style)
(type (or null (member :solid :tiled :opaque-stippled :stippled)) fill-style)
(type (or null (member :even-odd :winding)) fill-rule)
(type (or null (member :chord :pie-slice)) arc-mode)
(type (or null pixmap) tile stipple)
(type (or null fontable) font)
(type (or null (member :clip-by-children :include-inferiors)) subwindow-mode)
(type (or null (member :on :off)) graphics-exposures)
(type (or null (member :none) pixmap rect-seq) clip-mask)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or null integer (sequence integer)) dashes)
(type (or null (member :off :write-back :write-through) cache))))
(defmacro with-gc ((gc &key function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
graphics-exposures clip-x clip-y clip-mask clip-ordering
dash-offset dashes
cache)
&body body)
; Changes GC components within body, then restores them.
; If the cache mode is :off, this will implement save/restore by creating a
; temporary GC and doing a copy-gc to and from it.
; In a multi-process environment, this locks GC from concurrent use.
; The body is not surrounded by a with-display.
)
(defun copy-gc-components (src dst &rest keys)
(declare (type gc src dst)
(type (list gc-key) keys)))
(defun copy-gc (src dst)
(declare (type gc src dst))
; Copies all components.
)
(defun free-gc (gc)
(declare (type gc gc)))
(defun clear-to-background (window &key (x 0) (y 0) width height exposures-p)
; Passing in a zero width or height is a no-op.
; A null width or height translates into a zero value in the protocol request.
(declare (type window window)
(type integer x y)
(type (or null integer) width height)
(type boolean exposures-p)))
(defun copy-area (src gc src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gc gc)
(type integer src-x src-y width height dst-x dst-y)))
(defun copy-plane (src gc plane src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gc gc)
(type integer src-x src-y plane width height dst-x dst-y)))
(defun draw-point (drawable gc x y)
; Should be clever about appending to existing buffered protocol request.
(declare (type drawable drawable)
(type gc gc)
(type integer x y)))
(defun draw-points (drawable gc points &key relative-p)
(declare (type drawable drawable)
(type gc gc)
(type point-seq points)
(type boolean relative-p)))
(defun draw-line (drawable gc x1 y1 x2 y2 &key relative-p)
; Should be clever about appending to existing buffered protocol request.
(declare (type drawable drawable)
(type gc gc)
(type integer x1 y1 x2 y2)
(type boolean relative-p)))
(defun draw-lines (drawable gc points &key relative-p fill-p (shape :complex))
(declare (type drawable drawable)
(type gc gc)
(type point-seq points)
(type boolean relative-p fill-p)
(type (member :complex :non-convex :convex) shape)))
(defun draw-segments (drawable gc segments)
(declare (type drawable drawable)
(type gc gc)
(type seg-seq segments)))
(defun draw-rectangle (drawable gc x y width height &key fill-p)
; Should be clever about appending to existing buffered protocol request.
(declare (type drawable drawable)
(type gc gc)
(type integer x y width height)
(type boolean fill-p)))
(defun draw-rectangles (drawable gc rectangles &key fill-p)
(declare (type drawable drawable)
(type gc gc)
(type rect-seq rectangles)
(type boolean fill-p)))
(defun draw-arc (drawable gc x y width height angle1 angle2 &key fill-p)
; Should be clever about appending to existing buffered protocol request.
(declare (type drawable drawable)
(type gc gc)
(type integer x y width height angle1 angle2)
(type boolean fill-p)))
(defun draw-arcs (drawable gc arcs &key fill-p)
(declare (type drawable drawable)
(type gc gc)
(type arc-seq arcs)
(type boolean fill-p)))
; The following image routines are bare minimum. It may be useful to define
; some form of "image" object to hide representation details and format
; conversions. It also may be useful to provide stream-oriented interfaces
; for reading and writing the data.
(defun put-raw-image (drawable gc data
&key (start 0) depth x y width height (left-pad 0) format)
; Data must be a sequence of 8-bit quantities, already in the appropriate format
; for transmission; the caller is responsible for all byte and bit swapping and
; compaction. Start is the starting index in data; the end is computed from the
; other arguments.
(declare (type drawable drawable)
(type gc gc)
(type (sequence integer) data)
(type integer depth x y width height left-pad)
(type (member :bitmap :xy-pixmap :z-pixmap) format)))
(defun get-raw-image (drawable &key data (start 0) x y width height (plane-mask -1) format
(result-type '(vector (unsigned-byte 8))))
; If data is given, it is modified in place (and returned), otherwise a new sequence
; is created and returned, with a size computed from the other arguments and the
; returned depth. The sequence is filled with 8-bit quantities, in transmission
; format; the caller is responsible for any byte and bit swapping and compaction
; required for further local use.
(declare (type drawable drawable)
(type (or null (sequence integer)) data)
(type integer start x y width height plane-mask)
(type (member :xy-format z-format) format)
(values (sequence integer) depth visual)))
(defun draw-string (drawable gc x y string)
; For 8-bit indexes only.
; Should be clever about appending to existing buffered protocol request.
(declare (type drawable drawable)
(type gc gc)
(type integer x y)
(type string string)))
(defun draw-text (drawable gc items)
; For 8-bit indexes only.
; Items is a flat sequence containing both triples and pairs of the form:
; (integer x) (integer y) (string string)
; :font (fontable font)
(declare (type drawable drawable)
(type gc gc)
(type sequence items)))
(defun draw-string-image (drawable gc x y string)
; For 8-bit indexes only.
(declare (type drawable drawable)
(type gc gc)
(type integer x y)
(type string string)))
(defun draw-string16 (drawable gc x y array &key bytes-p)
; Should be clever about appending to existing buffered protocol request.
; If bytes-p is nil, then array should be an array of integers to be
; treated as 16-bit quantities, otherwise array should be a string of
; even length, treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gc gc)
(type integer x y)
(type array array)))
(defun draw-text16 (drawable gc items &key bytes-p)
; Items is a flat sequence containing both triples and pairs of the form:
; (integer x) (integer y) (array array)
; :font (fontable font)
; If bytes-p is nil, then array should be an array of integers to be
; treated as 16-bit quantities, otherwise array should be a string of
; even length, treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gc gc)
(type sequence items)))
(defun draw-string-image16 (drawable gc x y array &key bytes-p)
; If bytes-p is nil, then array should be an array of integers to be
; treated as 16-bit quantities, otherwise array should be a string of
; even length, treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gc gc)
(type integer x y)
(type array array)))
(defun create-colormap (visual window &key alloc-p)
(declare (type integer visual)
(type window window)
(type boolean alloc-p)
(values colormap)))
(defun free-colormap (colormap)
(declare (type colormap colormap)))
(defun copy-colormap-and-free (colormap)
(declare (type colormap colormap)
(values colormap)))
(defun install-colormap (colormap)
(declare (type colormap colormap)))
(defun uninstall-colormap (colormap)
(declare (type colormap colormap)))
(defun installed-colormaps (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence colormap))))
(defun alloc-color (colormap color)
(declare (type colormap colormap)
(type (or stringable color) color)
(values pixel screen-color exact-color)))
(defun alloc-color-cells (colormap colors &key (planes 0) contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors planes)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) (sequence mask))))
(defun alloc-color-planes (colormap colors
&key (reds 0) (greens 0) (blues 0)
contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors reds greens blues)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) red-mask green-mask blue-mask)))
(defun free-colors (colormap pixels &key (plane-mask 0))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type integer plane-mask)))
(defun store-color (colormap pixel spec &key (red-p t) (green-p t) (blue-p t))
(declare (type colormap colormap)
(type integer pixel)
(type (or stringable color) spec)
(type boolean red-p green-p blue-p)))
(defun store-colors (colormap specs &key (red-p t) (green-p t) (blue-p t))
(declare (type colormap colormap)
(type (repeat-seq (integer pixel) (color color)) specs)
(type boolean red-p green-p blue-p)))
(defun query-colors (colormap pixels &key (result-type 'list))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type type result-type)
(values (sequence color))))
(defun lookup-color (colormap name)
(declare (type colormap colormap)
(type stringable name)
(values screen-color true-color)))
(defun create-cursor (&key source mask x y foreground background)
(declare (type pixmap source)
(type (or null pixmap) mask)
(type integer x y)
(type color foreground background)
(values cursor)))
(defun create-glyph-cursor (&key source-font source-char mask-font mask-char
foreground background)
(declare (type font source-font)
(type integer source-char)
(type (or null font) mask-font)
(type (or null integer) mask-char)
(type color foreground background)
(values cursor)))
(defun free-cursor (cursor)
(declare (type cursor cursor)))
(defun recolor-cursor (cursor foreground background)
(declare (type cursor cursor)
(type color foreground background)))
(defun query-best-cursor (width height display)
(declare (type integer width height)
(type display display)
(values width height)))
(defun query-best-tile (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-best-stipple (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-extension (display name)
(declare (type display display)
(type stringable name)
(values major-opcode first-event first-error)))
(defun list-extensions (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence string))))
(defun keyboard-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(defsetf keyboard-mapping (display) (map)
(declare (type display display)
(type (sequence integer) map)))
(defun change-keyboard-control (display &key key-click-percent
bell-percent bell-pitch bell-duration
led led-mode key auto-repeat-mode)
(declare (type display display)
(type (or null (member :default) integer) key-click-percent
bell-percent bell-pitch bell-duration)
(type (or null integer) led key)
(type (or null (member :on :off)) led-mode)
(type (or null (member :on :off :default)) auto-repeat-mode)))
(defun keyboard-control (display)
; Order of key-value pairs is not specified.
(declare (type display display)
(values :key-click-percent integer
:bell-percent integer
:bell-pitch integer
:bell-duration integer
:led-mask integer
:global-auto-repeat (member :on :off)
:auto-repeats (bit-vector 256))))
(defun bell (display &optional (percent-from-normal 0))
; It is assumed that an eventual audio extension to X will provide more complete control.
(declare (type display display)
(type integer percent-from-normal)))
(defun pointer-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(defsetf pointer-mapping (display) (map)
(declare (type display display)
(type (sequence integer) map)))
(defun change-pointer-control (display &key acceleration threshold)
(declare (type display display)
(type (or null (member :default) rational) acceleration)
(type (or null (member :default) integer) threshold)))
(defun pointer-control (display)
(declare (type display display)
(values acceleration threshold)))
(defun set-screen-saver (display timeout interval blanking exposures)
; Timeout and interval are in seconds, will be rounded to minutes.
(declare (type display display)
(type (or (member :default) integer) timeout interval)
(type (member :yes :no :default) blanking exposures)))
(defun screen-saver (display)
; Returns timeout and interval in seconds.
(declare (type display display)
(values timeout interval blanking exposures)))
(defun activate-screen-saver (display)
(declare (type display display)))
(defun reset-screen-saver (display)
(declare (type display display)))
(defun add-access-hosts (display hosts &key protocol)
; A string must be acceptable as a host, but otherwise the possible types for
; hosts and protocol are not constrained, and will likely be very system dependent.
; The default protocol is system specific.
(declare (type display display)
(type sequence hosts)))
(defun rem-access-hosts (display hosts &key protocol)
; A string must be acceptable as a host, but otherwise the possible types for
; hosts and protocol are not constrained, and will likely be very system dependent.
; The default protocol is system specific.
(declare (type display display)
(type sequence hosts)))
(defun access-hosts (display &key protocol (result-type 'list))
; The default protocol is system specific.
; The type of host objects returned is not constrained, except that the hosts must
; be acceptable to add-access-hosts and rem-access-hosts.
(declare (type display display)
(type type result-type)
(values (sequence host) enabled-p)))
(defun access-control (display)
; setf'able
(declare (type display display)
(values boolean)))
(defun close-down-mode (display)
; setf'able
; Cached locally in display object.
(declare (type display display)
(values (member :destroy :retain-permanent :retain-temporary))))
(defun kill-client (display resource-id)
(declare (type display display)
(type resource-id resource-id)))
(defun kill-temporary-clients (display)
(declare (type display display)))
(defun make-event-mask (&rest keys)
; This is only defined for core events.
; Useful for constructing event-mask, pointer-event-mask, device-event-mask.
(declare (type (list event-mask-class) keys)
(values integer)))
(defun make-event-keys (event-mask)
; This is only defined for core events.
(declare (type integer event-mask)
(values (list event-mask-class))))
(defun make-state-mask (&rest keys)
; Useful for constructing modifier-mask, state-mask.
(declare (type (list state-mask-key) keys)
(values integer)))
(defun make-state-keys (state-mask)
(declare (type integer mask)
(values (list state-mask-key))))
(defmacro with-event-queue ((display) &body body)
; exclusive access to event queue
)
(defun event-listen (display)
(declare (type display display))
; Returns the number of events queued locally, if any, else nil.
)
(defun next-event (display &key handler (hang-p t) peek-p discard-p flush-p)
; If flush-p is true, first invokes display-flush-output.
; Invokes handler on each queued event until handler returns non-nil,
; and that returned object is then returned by next-event. If discard-p
; is true, then events for which handler returns nil are removed from
; the queue, otherwise they are left in place. If handler is a function,
; it is called with the event-key as its second argument. If handler is
; an array, it is expected to contain handler functions specific to each
; event class; the event code is used to index the array, fetching the
; appropriate handler. Handler is called with raw resource-ids, not with
; resource objects.
(declare (type display display)
(type (or (array (function (display &rest key-vals) t))
(function (display event-key &rest key-vals) t))
handler)
(type boolean hang-p peek-p)))
(defmacro event-case ((display &key hang-p peek-p discard-p flush-p)
&body clauses)
(declare (arglist (display &key hang-p peek-p discard-p flush-p)
(event-or-events ((&rest args) |...|) &body body) |...|))
; Macro convenience for a call to next-event with a lexical closure.
; Event-or-events is an event-key or a list of event-keys; they need not
; be typed as keywords. Args is the list of event components of interest;
; corresponding values (if any) are bound to variables with these names.
)
(defmacro declare-event (event-codes &rest declares)
; Used to indicate the keyword arguments for handler functions in next-event.
(declare (arglist event-key-or-keys &rest (type &rest keywords))))
(declare-event (:key-press :key-release :button-press :button-release)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
; for key-press and key-release, code is the keycode
; for button-press and button-release, code is the button number
(integer code))
(declare-event :motion-notify
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
(boolean hint-p))
(declare-event (:enter-notify :leave-notify)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
((member :normal :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual) kind)
(boolean focus-p))
(declare-event (:focus-in :focus-out)
(resource-id window)
((member :normal :while-grabbed :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual
:pointer :pointer-root :none)
kind))
(declare-event :keymap-notify
(resource-id window)
((bit-vector 256) keymap))
(declare-event :exposure
(resource-id window)
(integer x y width height)
(boolean last-p))
(declare-event :graphics-exposure
(resource-id drawable)
(integer x y width height major minor)
(boolean last-p))
(declare-event :no-exposure
(resource-id drawable)
(integer major minor))
(declare-event :visibility-notify
(resource-id window)
((member :unobscured :partially-obscured :fully-obscured) state))
(declare-event :create-notify
(resource-id window parent)
(integer x y width height border-width)
(boolean override-redirect-p))
(declare-event :destroy-notify
(resource-id event-window window))
(declare-event :unmap-notify
(resource-id event-window window)
(boolean configure-p))
(declare-event :map-notify
(resource-id event-window window)
(boolean override-redirect-p))
(declare-event :map-request
(resource-id parent window))
(declare-event :reparent-notify
(resource-id event-window window parent)
(integer x y)
(boolean override-redirect-p))
(declare-event :configure-notify
(resource-id event-window window)
(integer x y width height border-width)
((or null resource-id) above-sibling)
(boolean override-redirect-p))
(declare-event :gravity-notify
(resource-id event-window window)
(integer x y))
(declare-event :resize-request
(resource-id window)
(integer width height))
(declare-event :configure-request
(resource-id parent window)
(integer x y width height border-width)
((or null resource-id) above-sibling))
(declare-event :circulate-notify
(resource-id event-window window)
((member :top :bottom) place))
(declare-event :circulate-request
(resource-id parent window)
((member :top :bottom) place))
(declare-event :property-notify
(resource-id window)
(keyword atom)
((member :new-value :deleted) state)
(integer time))
(declare-event :selection-clear
(resource-id window)
(keyword selection)
(integer time))
(declare-event :selection-request
(resource-id window requestor)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :selection-notify
(resource-id window)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :colormap-notify
(resource-id window)
((or null resource-id) colormap)
(boolean new-p installed-p))
(declare-event :client-message
(resource-id window)
((member 8 16 32) format)
((sequence integer) data))
(defun event-queue-length (display)
(declare (type display display)
(values length)))
(defun queue-event-locally (display event-code &rest args &key append-p &allow-other-keys)
(declare (type display display)
(type integer event-code)
(type boolean append-p)))
∂03-Apr-87 0632 AVELLIS%IBACSATA.BITNET@forsythe.stanford.edu subscription
Received: from LINDY.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Apr 87 06:32:21 PST
Received: by lindy.STANFORD.EDU; Fri, 3 Apr 87 06:34:07 PST
Date: Fri, 3 Apr 87 06:35:25 PST
From: <AVELLIS%IBACSATA.BITNET@forsythe.stanford.edu>
To: CL-WINDOWS@sail.stanford.edu
Subject: subscription
Received: by IBACSATA (Mailer X1.23b) id 5394; Fri, 03 Apr 87 16:32:02 GMT
Date: Fri, 03 Apr 87 16:31:24 GMT
From: Gianna Avellis <AVELLIS@IBACSATA>
Subject: subscription
To: CL-WINDOWS@SAIL.STANFORD.EDU
Please subscribe me to the list.
Thank you in advance,
GIANNA AVELLIS
∂03-Apr-87 0839 dcmartin@ingres.berkeley.edu X/Common LISP library package (Beta release)
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 3 Apr 87 08:39:40 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
id AA29114; Fri, 3 Apr 87 08:36:24 PST
Message-Id: <8704031636.AA29114@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Cc: cl-windows@sail.stanford.edu, clx@zermatt.lcs.mit.edu
Precedence: priority-mail
In-Reply-To: Your message of Fri, 3 Apr 87 09:05 EST
Subject: X/Common LISP library package (Beta release)
Date: 03 Apr 87 08:36:21 PST (Fri)
Sender: dcmartin@ingres.berkeley.edu
Prompted by the CLX proposal...
This message is to announce the availability of a foreign function interface
CommonLISP X interface for protocol version 10. The sources are available by
public ftp from ingres.Berkeley.EDU in the directory pub/xcl. Documentation
is located in pub/xcl/doc and demo programs in pub/xcl/demo.
Individuals who cannot access the ARPAnet may receive the software for $100
tape charge from the EECS Department of UCB.
The XCL package currently only has support for the Franz, Inc foreign function
interface, but a Lucid interface should be completed shortly.
If anyone has questions about this software send mail to xcl-users-request
@ ingres.berkeley.edu.
dcm
-----
David C. Martin
-----
arpa: dcmartin@ingres.Berkeley.EDU
uucp: {ihnp4,decvax}!ucbvax!dcmartin
at&t: 415/642-9585 (O)
∂09-Apr-87 0703 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU revisions to CLX proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 07:03:34 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 10:01-EDT
Date: Thu, 9 Apr 87 10:05 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: revisions to CLX proposal
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870409100516.1.RWS@KILLINGTON.LCS.MIT.EDU>
In next-event and event-case, the flush-p argument should be
force-p, and causes display-force-output to be called.
Missing functions:
(defun force-gc-changes (gc)
;; Force any pending changes if the cache mode is :write-back.
(declare (type gc gc)))
;; Although atom-ids are not visible in the normal user interface, atom-ids might
;; appear in window properties and other user data, so conversion hooks are needed.
(defun intern-atom (display name)
(declare (type display display)
(type xatom name)
(values integer)))
(defun find-atom (display name)
(declare (type display display)
(type xatom name)
(values (or null integer))))
(defun atom-name (display atom-id)
(declare (type display display)
(type integer atom-id)
(values keyword)))
The multiple value keyword/value returns in the functions window-attributes,
drawable-geometry, query-pointer, text-extents, and keyboard-control
are not particularly tractable in CL, except in conjunction
with multiple-value-list or multiple-value-call. So, these
functions are changed to return a single property list instead.
In addition, the following macro forms are provided (with implementations
designed to avoid consing):
(defmacro let-from-window-attributes (bindings window &body body))
(defmacro setq-from-window-attributes (bindings window))
(defmacro let-from-drawable-geometry (bindings drawable &body body))
(defmacro setq-from-drawable-geometry (bindings drawable)
(defmacro let-from-query-pointer (bindings window &body body))
(defmacro setq-from-query-pointer (bindings window))
(defmacro let-from-text-extents (bindings (font string &key (cache-p t)) &body body))
(defmacro setq-from-text-extents (bindings font string &key (cache-p t)))
(defmacro let-from-keyboard-control (bindings display &body body))
(defmacro setq-from-keyboard-control (bindings display))
In each case, bindings is a list with elements of the form (var keyword), where
the keyword must be one from the plist type returned by the corresponding function.
[The syntax is a mixture of let and multiple-value-bind.] Note that the text-extents
macros are a bit different, due to the multiple arguments. The names and syntax are
the best that I could come up with; suggestions for improvement are welcome.
∂09-Apr-87 0745 RAM@C.CS.CMU.EDU revisions to CLX proposal
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 07:44:53 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 9 Apr 87 10:45:47-EDT
Date: Thu, 9 Apr 1987 10:45 EDT
Message-ID: <RAM.12293141952.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: revisions to CLX proposal
In-reply-to: Msg of 9 Apr 1987 10:05-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Gag me with a spoon! The keyword values hack was on my list of things
that had to be fixed, but the cure seems even more vile. There are
two obvious acceptable solutions:
-- Use as many positional values as necessary.
-- Return a structure.
Although I agree that with more than 10 or 15 positional values,
things to start to get a bit unmanagable, I have lived with interfaces
that did this sort of thing.
I also see returning a structure as acceptable in interfaces that
aren't obviously performance critical. Returning a structure is
probably always more efficienct than a plist, and I happen to think it
is much more tasteful.
Rob
∂09-Apr-87 0803 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU plist revisions to CLX proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 08:03:38 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 10:59-EDT
Date: Thu, 9 Apr 87 11:03 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: plist revisions to CLX proposal
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12293141952.BABYL@C.CS.CMU.EDU>
Message-ID: <870409110331.7.RWS@KILLINGTON.LCS.MIT.EDU>
I'm assuming that the macro forms will get used most of the time;
do you dislike them as well, or just the plist in the function?
I don't have any particularly strong arguments for a plist over a
structure, but I think having that many positional values just isn't
manageable. The only slight preference I had for the plist was
its possible use in an apply to change values back. If there
is general agreement that a structure would be better, fine with me.
∂09-Apr-87 0843 FAHLMAN@C.CS.CMU.EDU plist revisions to CLX proposal
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 08:42:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 9 Apr 87 11:43:48-EDT
Date: Thu, 9 Apr 1987 11:43 EDT
Message-ID: <FAHLMAN.12293152538.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: plist revisions to CLX proposal
In-reply-to: Msg of 9 Apr 1987 11:03-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
I think that using a structure to pass these bundled values around is
the right thing. If we go ahead and assume the existence of the Common
Lisp Object Standard (and I no longer see any reason to avoid this --
people will want to use it for their higher-level graphics hacking
anyway), then your macros aren't needed: WITH-SLOTS gives convenient
access by name to the various slots of the structure.
If there are still people out there who are fanatically CONS-averse,
neither the property list nor the structure solution will make them
happy, compared with a non-consing solution that uses positional
multiple values. One possibility might be to return structures, but to
provide all these structure-returning forms with an optional argument by
which the user can pass in a structure of the appropriate type that is
to be destructively modified. This avoids the need for consing up lots
of new structures, and also the need for copyingof values by the user
when the returned information is to be used outside the current dynamaic
extent.
-- Scott
∂09-Apr-87 1135 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: what package is the CLX stuff in?
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 11:34:33 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 14:32-EDT
Date: Thu, 9 Apr 87 14:36 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: what package is the CLX stuff in?
To: Fischer.pa@XEROX.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870409-094816-2359@Xerox>
Message-ID: <870409143610.0.RWS@KILLINGTON.LCS.MIT.EDU>
I'm not sure how/why so many people are missing this, but I sure
thought the proposal I sent out had XLIB listed as the package name.
∂09-Apr-87 1213 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU plist revisions to CLX proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 12:13:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 15:10-EDT
Date: Thu, 9 Apr 87 15:14 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: plist revisions to CLX proposal
To: Fahlman@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12293152538.BABYL@C.CS.CMU.EDU>
Message-ID: <870409151433.4.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 9 Apr 1987 11:43 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
your macros aren't needed: WITH-SLOTS gives convenient
access by name to the various slots of the structure.
If there are still people out there who are fanatically CONS-averse,
neither the property list nor the structure solution will make them
happy, compared with a non-consing solution that uses positional
multiple values.
The macro forms I proposed can be implemented entirely without consing,
and don't require positional multiple values either. I didn't claim
(or expect) they would be implemented on top of the plist/structure
returning function. If that had been the case, I would indeed have
agreed that with-slots was sufficient.
One possibility might be to return structures, but to
provide all these structure-returning forms with an optional argument by
which the user can pass in a structure of the appropriate type that is
to be destructively modified.
In most situations I would expect the functions to be called "on-the-fly",
and it would be inconvenient to squirrel away a pre-consed structure
somewhere.
∂09-Apr-87 1354 FAHLMAN@C.CS.CMU.EDU plist revisions to CLX proposal
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 13:54:37 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 9 Apr 87 16:55:35-EDT
Date: Thu, 9 Apr 1987 16:55 EDT
Message-ID: <FAHLMAN.12293209297.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: plist revisions to CLX proposal
The macro forms I proposed can be implemented entirely without consing,
and don't require positional multiple values either. I didn't claim
(or expect) they would be implemented on top of the plist/structure
returning function. If that had been the case, I would indeed have
agreed that with-slots was sufficient.
OK. I misunderstood what you were proposing.
[In the following, I speak of window attributes, but the other cases
would be handled in parallel ways.]
I could live with any of the following:
1. Only define functions that return and accept all the attributes of a
window as structures. Leave it up to the compiler to eliminate any
unneccessary structure-consing (though few compilers would bother).
2. Define functions that return and accept structures, as above, plus
another set of functions for accessing and modifying INDIVIDUAL
attributes of a window. Implementations in which it is expensive to
cross the boundary between Lisp and wherever the window data lives could
do some cacheing, if they want to be maximally tense.
3. Define functions that return and accept structures, plus the kinds of
macros RWS proposed earlier. This would be the way to go if we feel
that (a) these accesses occur often enough that excess consing would be
a significant load and (b) in these cases where performance matters, you
often want more than one attribute from a given window. I kind of doubt
that we're in this situation, but I'll defer to RWS's greater experience
in such matters.
If we go with plan 3, it might be a good idea to adopt syntax that more
closely parallels that of With-Slots. Something like the following
might work:
Define a Window-Attributes class (or structure) with slots named Visual,
Class, etc.
Define a function named Window-Attributes that takes a window and
returns a window-attributes structure, properly filled in. This would
be setf-able: you pass in a window-attributes structure as the new
value, and the window gets updated to match this.
Define a macro With-Window-Attributes to be functionally equivalent to
the following, except that it might never cons up the structure in
question. <W> is some anonymous internal gensym that the user can't get
at from within the body code.
(defmacro with-window-attributes ((window) &body body)
`(let ((<w> (window-attributes ,window)))
(with-slots ((<w> :class window-attributes))
,@body)
(setf (window-attributes ,window) <w>)))
Some cleverness might be used to avoid the final setf if none of the
slots were modified by code in the body. As in With-Slots, you could
have multiple window arguments with different prefixes so that the
body could copy attributes from one window to another, or whatever.
A similar set of widgets would be defined for drawable-geometry,
query-pointer, and so on.
-- Scott
∂09-Apr-87 1443 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU plist revisions to CLX proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 14:42:47 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 17:40-EDT
Date: Thu, 9 Apr 87 17:44 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: plist revisions to CLX proposal
To: Fahlman@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12293209297.BABYL@C.CS.CMU.EDU>
Message-ID: <870409174401.3.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 9 Apr 1987 16:55 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
3. Define functions that return and accept structures, plus the kinds of
macros RWS proposed earlier. This would be the way to go if we feel
that (a) these accesses occur often enough that excess consing would be
a significant load and (b) in these cases where performance matters, you
often want more than one attribute from a given window. I kind of doubt
that we're in this situation, but I'll defer to RWS's greater experience
in such matters.
For most of the functions, I don't expect that calls occur often enough
to worry about consing, but I was trying to make non-consing possible to
them's that cared, while still providing convenience in general. For
all of the functions in question, I think it more likely that one will
want two or three values, rather than one or all. Since the interface
is really intended for use when the display is remote, making multiple
protocol requests is both expensive and prone to race conditions.
Perhaps handling all of the functions in a uniform way isn't necessary.
I would say the only potentially "critical" functions are query-pointer
and text-extents, both of which might be called fairly often, and both
of which return a fair amount of stuff that any single call probably
won't care about. However, it might be that a few carefully selected
value subsets (as I have already done a bit of with drawable-size,
drawable-rectangle, and text-width) would be sufficient, in conjunction
with the full-structure returns for the general case, and eliminate
macro forms entirely.
(defmacro with-window-attributes ((window) &body body)
`(let ((<w> (window-attributes ,window)))
(with-slots ((<w> :class window-attributes))
,@body)
(setf (window-attributes ,window) <w>)))
I view this as overkill. I really consider the read-and-bind as the
important consideration; I don't think having a convenient way to change
them is at all important (and there are lots of return values involved
in the various functions for which setf isn't appropriate).
∂09-Apr-87 1701 FAHLMAN@C.CS.CMU.EDU plist revisions to CLX proposal
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 17:01:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 9 Apr 87 20:02:32-EDT
Date: Thu, 9 Apr 1987 20:02 EDT
Message-ID: <FAHLMAN.12293243327.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: plist revisions to CLX proposal
In-reply-to: Msg of 9 Apr 1987 17:44-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
I would say the only potentially "critical" functions are query-pointer
and text-extents, both of which might be called fairly often, and both
of which return a fair amount of stuff that any single call probably
won't care about. However, it might be that a few carefully selected
value subsets (as I have already done a bit of with drawable-size,
drawable-rectangle, and text-width) would be sufficient, in conjunction
with the full-structure returns for the general case, and eliminate
macro forms entirely.
Seems reasonable.
(defmacro with-window-attributes ((window) &body body)
`(let ((<w> (window-attributes ,window)))
(with-slots ((<w> :class window-attributes))
,@body)
(setf (window-attributes ,window) <w>)))
I view this as overkill. I really consider the read-and-bind as the
important consideration; I don't think having a convenient way to change
them is at all important (and there are lots of return values involved
in the various functions for which setf isn't appropriate).
Well, I don't care about the SETF part. The point was that if it's
worth having these macros, it might be worth tracking the With-Slots
syntax. Getting rid of them is better still.
-- Scott
∂09-Apr-87 2327 unido!gmdzi!jc@seismo.CSS.GOV plist revisions to CLX proposal
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 9 Apr 87 23:27:10 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA23069; Fri, 10 Apr 87 02:28:04 EDT
Received: by unido.uucp with uucp;
Fri, 10 Apr 87 06:49:47 +0100
Received: by gmdzi.UUCP id AA07046; Thu, 9 Apr 87 23:18:51 -0100
Received: by gmdzi.UUCP id AA06116; Thu, 9 Apr 87 20:07:27 -0100
Received: by unido.uucp with uucp;
Thu, 9 Apr 87 19:24:02 +0100
Received: by seismo.CSS.GOV (5.54/1.14)
id AA01426; Thu, 9 Apr 87 12:17:21 EDT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 08:42:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 9 Apr 87 11:43:48-EDT
Date: Thu, 9 Apr 1987 11:43 EDT
Message-Id: <FAHLMAN.12293152538.BABYL@C.CS.CMU.EDU>
Sender: unido!C.CS.CMU.EDU!FAHLMAN@seismo.CSS.GOV
From: "Scott E. Fahlman" <unido!C.CS.CMU.EDU!Fahlman@seismo.CSS.GOV>
To: "Robert Scheifler" <RWS@zermatt.lcs.mit.edu>
Cc: cl-windows@sail.stanford.edu
Subject: plist revisions to CLX proposal
In-Reply-To: Msg of 9 Apr 1987 11:03-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Status: R
I think that using a structure to pass these bundled values around is
the right thing. If we go ahead and assume the existence of the Common
Lisp Object Standard (and I no longer see any reason to avoid this --
people will want to use it for their higher-level graphics hacking
anyway), then your macros aren't needed: WITH-SLOTS gives convenient
access by name to the various slots of the structure.
If there are still people out there who are fanatically CONS-averse,
neither the property list nor the structure solution will make them
happy, compared with a non-consing solution that uses positional
multiple values. One possibility might be to return structures, but to
provide all these structure-returning forms with an optional argument by
which the user can pass in a structure of the appropriate type that is
to be destructively modified. This avoids the need for consing up lots
of new structures, and also the need for copyingof values by the user
when the returned information is to be used outside the current dynamaic
extent.
-- Scott
∂10-Apr-87 1055 DALY@IBM.COM passing structures to be destructively modified
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 10 Apr 87 10:55:07 PDT
Date: 10 April 1987, 11:39:32 EDT
From: Timothy Daly <DALY@ibm.com>
To: cl-windows@sail.stanford.edu
Message-Id: <041087.113933.daly@ibm.com>
Subject: passing structures to be destructively modified
I'd like to add a vote for scott's idea of being able to pass a structure
that would be destructively modified. Besides avoiding consing (not a
concern) it maintains eq-ness (a major concern) without having to
copy.
∂10-Apr-87 1821 ibuki!weaver@labrea.stanford.edu Berkeley CL X windows 10 available for KCL
Received: from LABREA by SAIL.STANFORD.EDU with TCP; 10 Apr 87 18:21:14 PDT
Received: by labrea.stanford.edu; Fri, 10 Apr 87 18:20:42 PST
Received: by ibuki.UUCP (1.4/4.7)
id AA6160551; Fri, 10 Apr 87 17:34:02 pst
Date: Fri, 10 Apr 87 17:34:02 pst
From: ibuki!weaver@labrea.stanford.edu (Eric Weaver)
Message-Id: <8704110134.AA6160551@ibuki.UUCP>
To: labrea!cl-windows@sail.stanford.edu
Subject: Berkeley CL X windows 10 available for KCL
We have a KCL version of David Martin's "XCL", available for whomever
has the courage to try it out. It is untested so far, except that it
loads into a KCL without error (our machine has no X just now).
Interested persons may contact us to arrange for copies at (415) 949-1126.
Ask for Eric Weaver.
∂11-Apr-87 0826 RAM@C.CS.CMU.EDU plist revisions to CLX proposal
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Apr 87 08:26:47 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 11 Apr 87 11:26:14-EDT
Date: Sat, 11 Apr 1987 11:26 EDT
Message-ID: <RAM.12293673628.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: plist revisions to CLX proposal
In-reply-to: Msg of 9 Apr 1987 11:03-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Date: Thursday, 9 April 1987 11:03-EDT
From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
To: RAM
Re: plist revisions to CLX proposal
I'm assuming that the macro forms will get used most of the time;
do you dislike them as well, or just the plist in the function?
I had a negative reaction to the macros because they seemed to be
adding a lot of conceptual complexity to an interface that seems
like it ought to be pretty simple. I am suspicious of features that
are harder to document than implement.
As a more general comment, I think that this proposal introduces a
fair amount of complexity to make things "lispy" and easy to use.
This seems to be incompatible with the claim that this interface will
be used primarily to implement a "toolkit". If this is really true,
then the emphasis should be on simplicity, efficiency and functional
completeness rather than on ease of use.
Do we really need to allow general sequences for all these arguments?
Do we really need all these keyword based interfaces?
I have some ideas for an object-oriented X interface, but I see very
little in CLX that would make me want to base my interface on CLX
rather than directly on our callout mechanism. In fact, programs that
directly used CLX would tend to clash with the o-o interface, since
CLX programs assume that they can usurp the entire event stream
instead of following some kind of discipline for demultiplexing.
Rob
∂12-Apr-87 1011 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU latest X11 protocol document
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 10:11:03 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 Apr 87 13:06-EDT
Date: Sun, 12 Apr 87 13:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: latest X11 protocol document
To: xpert@ATHENA.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
Message-ID: <870412131031.1.RWS@KILLINGTON.LCS.MIT.EDU>
The latest version (Alpha Update) of the X protocol document
is now available via anonymous ftp to zap.mit.edu (18.72.0.126)
as the file /pub/x11.spec. A Unix script to paginate the
document and produce a table of contents and an index is in
the file /pub/x11.spec.script. A list of the revisions from the
Alpha Test version is in the file /pub/x11.spec.update-revs.
If you do not have ftp access, and would like an email copy of
either the revisions or the complete protocol, send me mail,
and I will respond as time permits.
∂12-Apr-87 1308 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU plist revisions to CLX proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 13:08:00 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 Apr 87 16:04-EDT
Date: Sun, 12 Apr 87 16:08 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: plist revisions to CLX proposal
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12293673628.BABYL@C.CS.CMU.EDU>
Message-ID: <870412160833.3.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Sat, 11 Apr 1987 11:26 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
I had a negative reaction to the macros because they seemed to be
adding a lot of conceptual complexity to an interface that seems
like it ought to be pretty simple. I am suspicious of features that
are harder to document than implement.
I am now in agreement, and am working on a revision along the lines
suggested in previous mail, namely a structure as the return value, with
an optionally passed in structure to avoid consing, several functions
returning a subset of the values as multiple positional values, and the
elimination of the macros.
As a more general comment, I think that this proposal introduces a
fair amount of complexity to make things "lispy" and easy to use.
This seems to be incompatible with the claim that this interface will
be used primarily to implement a "toolkit". If this is really true,
then the emphasis should be on simplicity, efficiency and functional
completeness rather than on ease of use.
A toolkit is not a small piece of code, nor do I really believe we will
see standardization on just one toolkit in the near future. I think
ease of use is fairly important, particularly when it can be had without
significant loss of efficiency. The intent is that ease of use will
translate into simplicity at the next layer up, where (I believe) simplicity
and understandability are very important.
Do we really need to allow general sequences for all these arguments?
I don't know; what would you specify instead? The intent was to not preclude
particular implementations at the next level up, and there is the ubiquitous
issue of consing expense when there is a mismatch. I don't believe allowing
general sequences has to imply loss of efficiency when the argument is of
the desired (e.g., vector) type. Do you not believe this? I also don't
believe it adds substantial complexity to the implementation at this layer;
as I have said before, a substantial portion of the implementation is very
repetitive encoding/decoding, and can be handled well with appropriate
macro generation.
Do we really need all these keyword based interfaces?
Are you arguing from simplicity or efficiency grounds? Which interfaces do
you dislike, in particular? In general, keyword arguments are used when
there are zillions of (optional) arguments, and also I have tended to prefer
a single &key to a single &optional argument in cases where it seemed like
the addition of the keyword in the call would help readability. If there
is general agreement that these should be &optional instead, that could be
arranged. But it would help to have specific counter-proposals, or at
least more detailed arguments, rather than just general distaste reactions.
I have some ideas for an object-oriented X interface, but I see very
little in CLX that would make me want to base my interface on CLX
rather than directly on our callout mechanism. In fact, programs that
directly used CLX would tend to clash with the o-o interface, since
CLX programs assume that they can usurp the entire event stream
instead of following some kind of discipline for demultiplexing.
This confuses me. If the CLX layer imposes some kind of discipline, then
it preempts decisions at the next layer up, which is exactly what we want
to avoid. I'm not attempting to propose an interface that will allow
programs using both "direct" and an "o-o" interfaces on the same connection
to coexist; I don't see any way of making that work. The fact is that
the connection provides a single event stream, and there has to be, at
some level, something that pulls the events off the queue and does something
with them. I'm trying to provide (just) that functionality. An o-o interface
built on top would presumably either have a separate process dedicated to
this task, or else would impose a program structure similar to that proposed
in the C XToolkit. Perhaps you could elaborate on what it is that is different
about your "callout mechanism"?
∂12-Apr-87 1313 Gumby%AI.AI.MIT.EDU.#Chaos@XX.LCS.MIT.EDU passing structures to be destructively modified
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 13:13:24 PDT
Received: from BUDDY.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 Apr 87 16:09-EDT
Date: Sun, 12 Apr 87 16:13 EDT
From: David Vinayak Wallace <Gumby@AI.AI.MIT.EDU>
Subject: passing structures to be destructively modified
To: Timothy Daly <DALY@IBM.COM>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <041087.113933.daly@ibm.com>
Message-ID: <870412161326.7.GUMBY@BUDDY.AI.MIT.EDU>
Date: 10 April 1987, 11:39:32 EDT
From: Timothy Daly <DALY@ibm.com>
I'd like to add a vote for scott's idea of being able to pass a structure
that would be destructively modified. Besides avoiding consing (not a
concern) it maintains eq-ness (a major concern) without having to
copy.
Excuse my ignorance but I don't understand what this means. By copying
a structure or plist you'd remove any uniqueness. And stashing a
structure which is later modified could lead to later confusion, as the
modified structure will be eq to the saved one even though values might
not be what they were when you stashed it away.
Am I missing something obvious?
∂13-Apr-87 0852 rochester!tropix!dls@seismo.CSS.GOV Re: passing structures to be destructively modified
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 13 Apr 87 08:52:31 PDT
Received: from rochester.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA05079; Mon, 13 Apr 87 11:52:32 EDT
Received: by ur-seneca.arpa id AA11003 (4.12z); Mon, 13 Apr 87 10:48:39 est
Received: by tropix.UUCP (4.12/4.7)
id AA13701; Mon, 13 Apr 87 11:19:25 est
Date: Mon, 13 Apr 87 11:19:25 est
From: rochester!tropix!dls@seismo.CSS.GOV (David L. Snyder )
Message-Id: <8704131619.AA13701@tropix.UUCP>
To: cl-windows@sail.stanford.edu
Subject: Re: passing structures to be destructively modified
Cc: DALY@ibm.com
Date: 10 April 1987, 11:39:32 EDT
From: Timothy Daly <rochester!seismo!ibm.com!DALY>
To: cl-windows@sail.stanford.edu
Message-Id: <041087.113933.daly@ibm.com>
Subject: passing structures to be destructively modified
I'd like to add a vote for scott's idea of being able to pass a structure
that would be destructively modified. Besides avoiding consing (not a
concern) it maintains eq-ness (a major concern) without having to
copy.
I also vote for structures, both for the sake of eq testing, and
local smashing. Presumably there is to be some structure field with
extensible slots, to accomodate special needs, local particulars, &tc?
∂13-Apr-87 1305 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: passing structures to be destructively modified
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87 13:05:00 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Apr 87 15:52-EDT
Date: Mon, 13 Apr 87 15:56 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: passing structures to be destructively modified
To: rochester!tropix!dls@seismo.CSS.GOV, cl-windows@sail.stanford.edu
cc: DALY@ibm.com
In-Reply-To: <8704131619.AA13701@tropix.UUCP>
Message-ID: <870413155602.6.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Mon, 13 Apr 87 11:19:25 est
From: rochester!tropix!dls@seismo.CSS.GOV (David L. Snyder )
Date: 10 April 1987, 11:39:32 EDT
From: Timothy Daly <rochester!seismo!ibm.com!DALY>
I'd like to add a vote for scott's idea of being able to pass a structure
that would be destructively modified. Besides avoiding consing (not a
concern) it maintains eq-ness (a major concern) without having to
copy.
I also vote for structures, both for the sake of eq testing, and
local smashing. Presumably there is to be some structure field with
extensible slots, to accomodate special needs, local particulars, &tc?
Since you both seem to understand each other, and I don't think I understand
either of you, perhaps one of you could restate at longer length?
Scott's basic idea was to have (e.g.) window-attributes fill in a structure
either newly consed up or optionally passed in. That structure was NOT the
same structure as the window object itself, so I'm not sure what eq-ness
you are concerned with. As for "special needs" and "local particulars",
the intent was to avoid imposing a requirement of either defstruct or
defclass implementation on the objects, but just define a functional
interface compatible with either implementation. True stream and object
oriented interfaces would be provided at higher levels, as indicated
in Mike McMahon's message on layers. If you do not think this is
appropriate, perhaps you could elucidate?
∂13-Apr-87 1354 Oren%Tilde%ti-csl.csnet@RELAY.CS.NET CLX With-Display speed hack
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 Apr 87 13:54:11 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac03849; 13 Apr 87 16:36 EDT
Received: from ti-csl by RELAY.CS.NET id aa25604; 13 Apr 87 16:32 AST
Received: from SI (si.ARPA) by tilde id AA03425; Mon, 13 Apr 87 14:15:17 cdt
Message-Id: <2754332029-1063447@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 13 Apr 87 15:13:49 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: CLX With-Display speed hack
I think that two kinds of locking would be better in CLX. One lock for
request generation, and another lock for requests that expect a reply.
For example:
(defun draw-string (...)
(WITH-DISPLAY-REQUEST (display)
(send-draw-string-request ...)))
(defun get-property (...)
(WITH-DISPLAY-REPLY (display)
(WITH-DISPLAY-REQUEST (display)
(send-get-property-request ...))
;; While waiting for the reply, other processes may
;; send requests that don't expect replies.
(wait-for-reply display)
(process-reply ...)))
Another advantage of having two kinds of locks is that since very little
happens inside the body of a WITH-DISPLAY-REQUEST, LISPM's can can expand
it into a WITHOUT-INTERRUPTS, which is faster than holding a lock within
an unwind-protect.
I propose WITH-DISPLAY have an optional parameter specifying the type
of the lock. Some implementations may ignore the optional parameter.
(defmacro with-display ((display &optional (FOR :reply)) &body body)
; This macro is for use in a multi-process environment. It provides
; exclusive access to the local display object for request generation
; and reply processing.
;
; FOR may be :REPLY or :REQUEST :SHORT-REQUEST. :REPLY is for locking
; around requests that may or may not receive replies. :SHORT-REQUEST
; is a speed hack for locking around requests that don't receive
; replies. :REQUEST is for locking around requests such as
; PUT-RAW-IMAGE that don't expect a reply, where its undesirable to
; lock out other processes.
;
; Except where noted, all of the routines below should be thought of as
; containing an implicit with-display, so that correct synchronization
; is always provided at the interface level on a per-call basis.
; Nested uses of this macro will work correctly. This macro does not
; prevent concurrent event processing; see with-event-queue.
)
-- LaMott
∂13-Apr-87 1427 carter%silicon@cs.utah.edu de-subscription
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87 14:26:59 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA09733; Mon, 13 Apr 87 15:28:30 MDT
Received: by silicon.UTAH.EDU (4.30/4.40.2)
id AA04229; Mon, 13 Apr 87 15:28:15 mdt
Date: Mon, 13 Apr 87 15:28:15 mdt
From: carter%silicon@cs.utah.edu (Tony M. Carter)
Message-Id: <8704132128.AA04229@silicon.UTAH.EDU>
To: cl-windows@sail.stanford.edu
Subject: de-subscription
Please remove me from the mailing list
carter@silicon.utah.edu OR carter@cs.utah.edu
∂13-Apr-87 2109 janson@ATHENA.MIT.EDU common lisp X interface
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87 21:09:33 PDT
Received: by ATHENA (5.45/4.7)
id AA04752; Mon, 13 Apr 87 23:08:21 EST
From: <janson@ATHENA.MIT.EDU>
Received: by POSEIDON.MIT.EDU (5.45/4.7) id AA09998; Mon, 13 Apr 87 23:07:34 EST
Message-Id: <8704140407.AA09998@POSEIDON.MIT.EDU>
To: cl-windows@sail.stanford.edu, xpert
Subject: common lisp X interface
Date: Mon, 13 Apr 87 23:07:32 EST
the recent notice re a "standard Common Lisp interface to
X Version 11" described it as an alternative (in addition to) the
Xlib interface, in that it will provide the equivalent support
but will keep as much of the implementation as possible within Lisp.
This would appear to require that CL implementations in unix environments
be provided with a very low level (C based?) protocol interface upon
which to build.
Does anyone know what vendors like DEC, HP, and Sun are planning?
I'm actually interested to use such a foreign-function interface from
CScheme, but the CL version would be a good base.
james anderson.
department of architecture 9-526
MIT Cambridge MA 02139
617-253-0782
∂14-Apr-87 0826 FAHLMAN@C.CS.CMU.EDU common lisp X interface
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 08:26:37 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 14 Apr 87 11:24:45-EDT
Date: Tue, 14 Apr 1987 11:24 EDT
Message-ID: <FAHLMAN.12294459782.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: <janson@ATHENA.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
Subject: common lisp X interface
In-reply-to: Msg of 14 Apr 1987 00:07-EDT from <janson at ATHENA.MIT.EDU>
This would appear to require that CL implementations in unix environments
be provided with a very low level (C based?) protocol interface upon
which to build.
Does anyone know what vendors like DEC, HP, and Sun are planning?
The Common Lisp language spec (current or proposed) does not require any
sort of call-out mechansism, but all of the vendors you name have some
sort of call-out from Common Lisp to C. I'm not sure whether all of
them are general enough to support everything in the Xlib interface in a
convenient way, however.
-- Scott
∂14-Apr-87 0906 RAM@C.CS.CMU.EDU XCL comments
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 09:06:26 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 14 Apr 87 12:00:56-EDT
Date: Tue, 14 Apr 1987 12:00 EDT
Message-ID: <RAM.12294466371.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: XCL comments
In-reply-to: Msg of 12 Apr 1987 16:08-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
A lot of my initial objection to the XCL proposal was due to by impression that
it wouldn't mesh very will with the kind of object oriented substrate that I am
interested in. I have since realized that this is not the case. It would be
quite reasonable for XCL windows to be CLOS objects. I think that this
possible connection should be emphasized more, and in particular, I think that
there should be a standard way to get X events to cause messages to be sent to
the window object.
My main reservation about the current proposal is with the event handling. The
biggest problem is with the use of keyword arguments to represent event
components. In addition to being distasteful, this will result in hundreds of
bytes of garbage being consed for every key you type. I suggest that events be
represented by structures, with each distinct kind of event having a distinct
structure type.
Applications that are worried about consing can use the FREE-EVENT function
to explicitly reclaim event structures. With NEXT-EVENT, we can't supply a
structure to be destructively modified since we don't know what type the next
event is going to be.
Using a structure to represent events also cleans up the interface to the
SEND-EVENT functions, since we don't have to pass in the components using
&ALLOW-OTHER-KEYS.
The (non-keyword) name of the event structure type should be used as a
symbolic representation of the event kind, replacing the event-keys
keywords. It would be confusing and redundant to have keyword names
in addition to the structure type names.
Other more minor suggestions:
-- There *must* be start and end arguments to DRAW-STRING (and presumably
DRAW-STRING-IMAGE). I would prefer optional args rather than keywords (as
in SUBSEQ). I don't really care about being able to do this in DRAW-TEXT,
since I don't intend to use it.
-- There should be a timeout argument to NEXT-EVENT. This is a very useful
thing to have, and is impossible to simulate if it doesn't exist. If a
non-null timeout is specified, then NEXT-EVENT will return :TIMEOUT if the
timeout is exceeded.
I also think it is worth specifying a simple event interface using CLOS. Each
event type will also be a specializable CLOS operation. Methods for these
operations have one argument: the EVENT structure. There are two functions
that provide an interface to this mechanism:
(defun send-event-messages (window)
(declare (type window window))
...)
SEND-EVENT-MESSAGES specifies that when an event on WINDOW is received, the
corresponding message will be sent to the window object.
There also needs to be some way to create a specific type of window object,
doing any necessary bookkeeping to maintain the resource-id => object
translation. I don't know enough about CLOS to know whether this can be done
by the default constructor.
(defun wait-for-event (&key timeout windows displays if-unknown-window)
(declare (type (or number null) timeout))
(declare (type list windows))
(declare (type (member :discard :send :leave-in-queue) if-unknown-window))
...)
WAIT-FOR-EVENT waits for some event to arrive and then sends a message to the
appropriate window, returing the event when it is done. If a non-null timeout
is specified, then it will return :TIMEOUT if no relavent event arrives in the
specified interval. If a non-null windows list is specifed, then it will only
return when an event happens to one of the specified windows, although it will
still dispatch events that arrive for other windows.
If Displays is specified, then it will only read events on the specified
displays, otherwise it reads events on all open displays. If an event arrives
for a window that hasn't had SEND-EVENT-MESSAGES done on it, then the value of
If-Unknown-Window is used to tell what to do:
:Discard
The event is discarded.
:Send
Send the event anyway (the default). This will presumably result in some
kind of unknown message error.
:Leave-In-Queue
The event is left in the local queue, and can still be read using
NEXT-EVENT.
I also have some questions about possible strangenesses in the interface:
-- Why does ROTATE-PROPERTIES use the opposite meaning for Delta from the one
in the protocol?
-- Why allow an atom to be a string? This makes it harder to use an EQ
hash to maintain the atom translations, although the interface could just
intern the string in the keyword package and then EQ hash. Is this to make
mixed-case atoms (such as font properties (sigh...)) less bletcherous?
-- Why are these names changed from the protocol spec?
ChangeProperty => STORE-PROPERTY
ListFonts => MATCHING-FONTS
ListFontsWithInfo => MATCHING-FONTS-AND-PROPERTIES
∂14-Apr-87 1131 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU CLX With-Display speed hack
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 11:31:37 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 14 Apr 87 14:18-EDT
Date: Tue, 14 Apr 87 14:22 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX With-Display speed hack
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2754332029-1063447@SI>
Message-ID: <870414142255.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Mon, 13 Apr 87 15:13:49 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
I think that two kinds of locking would be better in CLX. One lock for
request generation, and another lock for requests that expect a reply.
For example:
(defun draw-string (...)
(WITH-DISPLAY-REQUEST (display)
(send-draw-string-request ...)))
(defun get-property (...)
(WITH-DISPLAY-REPLY (display)
(WITH-DISPLAY-REQUEST (display)
(send-get-property-request ...))
;; While waiting for the reply, other processes may
;; send requests that don't expect replies.
(wait-for-reply display)
(process-reply ...)))
Another advantage of having two kinds of locks is that since very little
happens inside the body of a WITH-DISPLAY-REQUEST, LISPM's can can expand
it into a WITHOUT-INTERRUPTS, which is faster than holding a lock within
an unwind-protect.
I propose WITH-DISPLAY have an optional parameter specifying the type
of the lock. Some implementations may ignore the optional parameter.
There are both implementation and semantic issues coupled here. The
semantic issues are 1) whether generation of the next request (by
another process) can overlap with receipt of a reply to the last
request, and 2) whether the programmer needs to be explicit in
with-display about what goes on in the body. I don't see anything
particularly wrong with 1), although I don't think it gains you that
much in terms of concurrency in the normal case, since by far the most
common case is issuing requests for which there is no reply. However, I
think making things visible in with-display is a bad idea.
Request generation isn't quite as simple as you seem to think. I'm
assuming the implementation will be along the lines of having an output
buffer and a (TCP) stream. Requests get encoded into the buffer until
the buffer fills, and then it is written to the stream. There is always
the possibility that the output buffer will be(come) full when
generating a request, so there is always the possibility that you will
have to write data to the stream. This write may well block (it
certainly can for a TCP stream), so it can't be done inside a
without-interrupts. Even if the stream implementation itself provides
internal locking (and it isn't clear to me that TCP streams do in either
the TI or Symbolics systems), there will be "big" X requests (like
put-raw-image) that require more than one write to the stream. This
means there HAS to be a "long" way of request-locking the display that
allows a process block, and so cannot be implemented using
without-interrupts. So even if you try to use without-interrupts for
the "normal" case, you will have to both check for buffer-too-full and
for a conflicting "long" form of request-locking, and be able to wait
for such a long-form lock to be released.
The intent of with-display is to surround multiple calls, so one can
amortize the locking cost. I see no reason why one should desire to
special-case a without-interrupts form of locking in with-display; it
ought to always use the "long" form of request-locking. Forcing the
caller declare whether the body will use replies or not is just asking
for bugs, and is asking for the kind of knowledge the interface is
trying to hide. Allowing the caller to semi-implicitly use
without-interrupts is even more prone to bugs.
Rather than having with-display specify the locking mode, it seems much
better to say that with-display always locks for requests, and
individual requests just additionally lock for replies as needed.
Trying to amortize the cost of reply-locking doesn't seem important; the
whole protocol is essentially geared at minimizing the use of replies
anyway. (I suppose one could allow the specification in with-display as
an optimization, but it should be only that, it shouldn't cause bugs to
fail to specify it.)
Within the CLX internals, locking separately for request and reply is
reasonable, but if you are going to do it, it should be done "right",
meaning allowing overlap of next request and last reply, meaning locking
regions must overlap rather than nest. Redoing your get-property
example (and ignoring unwind issues):
(request-lock display)
(encode-get-property-request ...)
(force-output display)
(reply-lock display)
(request-unlock display)
(wait-for-reply display)
(process-reply ...)
(reply-unlock display)
Does all this make sense?
While I'm close to the subject, I personally try to avoid designing
around without-interrupts whenever possible; it only gets you into
trouble. It doesn't generalize to multi-processor architectures, and it
inevitably leads to problems down the line with either a process-block
inside a without-interrupts, or with very long critical sections where
you didn't expect them. I think the current TI and Symbolics window
systems are a good example. TV:SHEET locking is done using
without-interrupts, a fact you will find by browsing the documentation
(source), but not be reading the manual. In ancient days I suppose
window operations were pretty quick, but that isn't the case any more
with many graphics operations. Furthermore, when I came around and
tried to slip an X stream in under the covers in place of the
memory-mapped frame buffer, lo and behold a write-to-stream call might
end of blocking inside the without-interrupts. If your normal-case
process-locking mechanisms are so expensive that you have to resort to
without-interrupts, you should rethink your architecture.
∂14-Apr-87 1351 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU XCL [sic] comments
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 13:51:13 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 14 Apr 87 16:47-EDT
Date: Tue, 14 Apr 87 16:50 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: XCL [sic] comments
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12294466371.BABYL@C.CS.CMU.EDU>
Message-ID: <870414165059.1.RWS@KILLINGTON.LCS.MIT.EDU>
[I've been calling it "CLX"; David Martin calls his V10 interface "XCL".]
Date: Tue, 14 Apr 1987 12:00 EDT
Message-ID: <RAM.12294466371.BABYL@C.CS.CMU.EDU>
I think that this possible
[CLOS] connection should be emphasized more,
You mean just in documentation (send me prose), or in interface change?
and in particular, I think that
there should be a standard way to get X events to cause messages to be sent to
the window object.
I will agree, but since I'm far from certain that such dispatching
should be the ONLY mechanism, or that we can quickly agree on all
aspects of such object-based dispatching, the intent was to push such
issues up to the next layer. This is exactly what has been done in the
C Xlib vs. Toolkit. Are you disagreeing with this (and if so, can you
make a concrete proposal for others to shoot at)?
The
biggest problem is with the use of keyword arguments to represent event
components. In addition to being distasteful, this will result in hundreds of
bytes of garbage being consed for every key you type.
Huh? Where does the consing come from? The whole reason we designed
the interface that way was to AVOID consing! Please explain.
I suggest that events be
represented by structures, with each distinct kind of event having a distinct
structure type.
Within the current proposal, one can define simply define a dispatch
array, where each function is a structure-conser, and get exactly what
you desire. We are simply providing more flexibility than you in
particular care for, yes? If you want us to make your case even easier,
we could certainly change the dispatch function to take in the display
and event-key by keyword argument as well, and then the functions could
directly be the appropriate make-<structure>s.
Applications that are worried about consing can use the FREE-EVENT function
to explicitly reclaim event structures.
This was one reason we decided on the more flexible interface;
free-event is just asking for bugs.
Using a structure to represent events also cleans up the interface to the
SEND-EVENT functions, since we don't have to pass in the components using
&ALLOW-OTHER-KEYS.
Perhaps this is just personal taste; having to cons up a structure only to
have it torn down again doesn't seem particularly cleaner to me.
Other more minor suggestions:
-- There *must* be start and end arguments to DRAW-STRING (and presumably
DRAW-STRING-IMAGE).
Absolutely. This was an oversight. Should also be in draw-string16 and
draw-string-image16.
I would prefer optional args rather than keywords (as
in SUBSEQ).
I prefer keywords, in keeping with all the CL string (as opposed to sequence)
operations, as well as write-string.
I don't really care about being able to do this in DRAW-TEXT,
since I don't intend to use it.
I agree start/end should not be provided for this function.
-- There should be a timeout argument to NEXT-EVENT. This is a very useful
thing to have, and is impossible to simulate if it doesn't exist. If a
non-null timeout is specified, then NEXT-EVENT will return :TIMEOUT if the
timeout is exceeded.
I kind of agree with you, but why is it that CL doesn't? Why doesn't CL's listen
take a timeout, or why isn't there a general wait-with-timeout for streams, or
any sort of timeout mechanism at all besides sleep? I am hesitant to require
something that may not be possible to implement uniformly.
I also think it is worth specifying a simple event interface using CLOS. Each
event type will also be a specializable CLOS operation. Methods for these
operations have one argument: the EVENT structure. There are two functions
that provide an interface to this mechanism:
(defun send-event-messages (window)
(declare (type window window))
...)
SEND-EVENT-MESSAGES specifies that when an event on WINDOW is received, the
corresponding message will be sent to the window object.
What does this really mean? Are you proposing this on top of the existing
interface, or within it, or instead of? Does it imply an automatic filtering
on events as seen by processes doing next-events, or does it imply that there is
effectively a daemon process that is continually doing a next-event, and next-event
is no longer part of the interface?
There also needs to be some way to create a specific type of window object,
doing any necessary bookkeeping to maintain the resource-id => object
translation. I don't know enough about CLOS to know whether this can be done
by the default constructor.
It is unclear to me whether a CLOS (or stream-based) window object
should include a CLX window as super-class, or as just another value in
an instance variable, but I suspect the latter is more appropriate. To
a degree it depends on whether you want to hide or expose graphics
contexts in the interface. Some of these issues may become clearer when
a higher-level graphics interface gets proposed.
(defun wait-for-event (&key timeout windows displays if-unknown-window)
(declare (type (or number null) timeout))
(declare (type list windows))
(declare (type (member :discard :send :leave-in-queue) if-unknown-window))
...)
Again, I suspect this is just one example of what one might desire at
the next level up (and you will find those that will argue about
you-call-us versus we'll-call-you). I certainly don't want to require
CLX to be implemented using CLOS.
-- Why does ROTATE-PROPERTIES use the opposite meaning for Delta from the one
in the protocol?
To keep the "natural" default of one consistent with the definition of CL rotatef,
and also to be consistent with CL ash.
-- Why allow an atom to be a string? This makes it harder to use an EQ
hash to maintain the atom translations, although the interface could just
intern the string in the keyword package and then EQ hash. Is this to make
mixed-case atoms (such as font properties (sigh...)) less bletcherous?
All the standard properties have been changed in the protocol spec to
uppercase with underscore, to make life simpler for Lisp. I added
strings as atoms because I got responses from some people that they
thought strings were more natural to use than keywords. I have no
strong feelings. The implementation could always keep two separate hash
tables (one EQ and one EQUAL) assuming a program will tend to use just
one or the other, and pay the extra roundtrips when they mix usage.
-- Why are these names changed from the protocol spec?
ChangeProperty => STORE-PROPERTY
ListFonts => MATCHING-FONTS
ListFontsWithInfo => MATCHING-FONTS-AND-PROPERTIES
No particularly good reason. Consider them changed to agree with the
protocol spec.
∂14-Apr-87 1410 burdorf@rand-unix.ARPA Re: plist revisions to CLX proposal
Received: from RAND-UNIX.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87 14:10:32 PDT
Received: by rand-unix.arpa; Tue, 14 Apr 87 13:47:30 PST
Message-Id: <8704142147.AA08807@rand-unix.arpa>
To: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Cc: Fahlman@c.cs.cmu.edu, cl-windows@sail.stanford.edu, burdorf@rand-unix.ARPA
Subject: Re: plist revisions to CLX proposal
In-Reply-To: Your message of Thu, 9 Apr 87 17:44 EDT.
<870409174401.3.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 14 Apr 87 13:47:23 PST
From: burdorf@rand-unix.ARPA
∂14-Apr-87 1611 RAM@C.CS.CMU.EDU XCL [sic] comments
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 16:11:42 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 14 Apr 87 19:12:37-EDT
Date: Tue, 14 Apr 1987 19:12 EDT
Message-ID: <RAM.12294544961.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: XCL [sic] comments
In-reply-to: Msg of 14 Apr 1987 16:50-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
14-Apr-87 17:53:06-EDT,7149;000000000000
Date: Tuesday, 14 April 1987 16:50-EDT
From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Re: XCL [sic] comments
Date: Tue, 14 Apr 1987 12:00 EDT
Message-ID: <RAM.12294466371.BABYL@C.CS.CMU.EDU>
The biggest problem is with the use of keyword arguments to
represent event components. In addition to being distasteful, this
will result in hundreds of bytes of garbage being consed for every
key you type.
Huh? Where does the consing come from? The whole reason we designed
the interface that way was to AVOID consing! Please explain.
In our implementation (and probably many others) keyword args are implemented
using rest args, so they cons. I believe that there are something like 11
fields in the event you get for a key being pressed event. 11 * 2 * 8 = 176
bytes consed for every call with those event keywords. At least at first
glance it also looked like these keys might be passed to more than one call for
each event, introducing another factor of two or so. Even if you never
explicitly reclaim event structures you will cons four times less using a
structure.
I am willing to concede that explicitly reclaiming event structures is more
dangerous than letting the system worry about it, but explicit storage
allocation is often necessary on conventional hardware.
Explicit Using a structure to represent events also cleans
up the interface to the SEND-EVENT functions, since we don't have
to pass in the components using &ALLOW-OTHER-KEYS.
Perhaps this is just personal taste; having to cons up a structure only to
have it torn down again doesn't seem particularly cleaner to me.
Well, I don't really know how those functions are used, but I was guessing
that they were often used to relay an event that you read from somewhere,
rather than shoving in events that you created.
-- There should be a timeout argument to NEXT-EVENT. [...]
I kind of agree with you, but why is it that CL doesn't? Why doesn't
CL's listen take a timeout, or why isn't there a general
wait-with-timeout for streams, or any sort of timeout mechanism at all
besides sleep? I am hesitant to require something that may not be
possible to implement uniformly.
Well, I guess you could say that it is an oversight, although there might
also be problems with doing timeouts in cretinous environments which CL
wanted to be able to run in. It seems to me that the presence of a window
system suggests a system modern enough to allow this. I agree that this
may be ugly to implement in some cases, but it also very useful. One of
the routine hassles in porting Hemlock is figuring out some way to
implement EDITOR-SLEEP, which is like sleep, but is defined to return when
input is available.
I also think it is worth specifying a simple event
interface using CLOS. [...]
What does this really mean? Are you proposing this on top of the
existing interface, or within it, or instead of?
I guess within it, since it might be awkward to implement it on top of
next-event. I don't have any problem with providing direct access to the
event stream, but I think that you badly need some kind of automatic
demultiplexing mechanism for even simple applications.
Does it imply an automatic filtering on events as seen by processes
doing next-events, or does it imply that there is effectively a daemon
process that is continually doing a next-event, and next-event is no
longer part of the interface?
Well, although I was to some degree making up this proposal on the fly, it
is based on the mechanism used in our implementation to do arbitrary things
when input arrives. Since we don't have lightweight processes, it is not
possible to have a background process that does the event dispatching,
although this isn't necessarily very obvious to the input handlers. The
function equivalent to Wait-For-Input is responsible for waiting for
something to happen and then calling the appropriate handler.
I don't have enough experience with multi-thread systems to know how this
would work in such a system, but I suspect that having a background process
doing the dispatching would be the right thing.
As to whether the NEXT-EVENT streams are being filtered, it is my idea that
when a program opens a display it will usually stick to one interface or
the other, but specifying :leave-in-queue to Wait-For-Input would have the
effect of filtering out the events on objectified windows while leaving the
rest behind.
The reason that I'm pushing for this o-o interface is that I was hoping to
get a simple o-o interface without having to wait for the ultimate toolkit
to come out. I don't have a great deal of confidence that it will be
possible to agree on anything that complex. The only reason that
converging on an X interface standard is tractable is that X is already
well specified. It seems that a message based dispatching mechanism like
this provides a substrate on which you can do experimental programming
using lots of different "toolkits" without committing to any one.
Rob
∂14-Apr-87 2143 Moon@STONY-BROOK.SCRC.Symbolics.COM plist revisions to CLX proposal
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87 21:42:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 116161; Wed 15-Apr-87 00:41:47 EDT
Date: Wed, 15 Apr 87 00:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: plist revisions to CLX proposal
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, Rob MacLachlan <RAM@C.CS.CMU.EDU>,
Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: clx@ZERMATT.LCS.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870412160833.3.RWS@KILLINGTON.LCS.MIT.EDU>,
<870412145724.9.RWS@KILLINGTON.LCS.MIT.EDU>,
<RAM.12293673628.BABYL@C.CS.CMU.EDU>,
<FAHLMAN.12293243327.BABYL@C.CS.CMU.EDU>,
<870409174401.3.RWS@KILLINGTON.LCS.MIT.EDU>,
<FAHLMAN.12293209297.BABYL@C.CS.CMU.EDU>,
<870409151433.4.RWS@KILLINGTON.LCS.MIT.EDU>,
<FAHLMAN.12293152538.BABYL@C.CS.CMU.EDU>,
<870409110331.7.RWS@KILLINGTON.LCS.MIT.EDU>,
<RAM.12293141952.BABYL@C.CS.CMU.EDU>,
<870409100516.1.RWS@KILLINGTON.LCS.MIT.EDU>,
<870406090550.3.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870415004116.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
This message is only about the part of CLX that involves functions that
return lots of values.
I've thought about this more, and I think a mid-course correction
is called for. I think the macros I suggested were a mistake. I think
the alternate macros discussed in the referenced mail were a mistake.
I think returning a plist is a mistake. I think returning a structure,
which seems to be what you have converged on, is a mistake.
The more natural interface, I think, would be to provide a separate
access function for each value. If the user wants to get several
values, he can call several access functions. SETF of the access
functions works nicely for altering values.
Let's back off and ask -why- you need to return so many values from a
single function call. I can think of four reasons why you might want to
use a single call that returns many values in preference to multiple
calls, each of which returns one value, and a single call that sets many
values in preference to multiple calls, each which sets one value. Are
any of these the real reason?
(1) Tastefulness. I think the discussion of many alternative ways
of getting the multiple values, all of which are ugly and many of
which are inefficient, has discredited this.
(2) Efficiency, because function calling is too slow. I doubt that
this is a real problem. More specifically, in implementations where
it is a real problem, I doubt that returning many values from one
function call makes a significant dent in the problem.
(3) Efficiency, because the X protocol wants to batch up the reads
or writes into a single request. In my opinion, this would be better
handled by caching (for reads) and buffering (for writes), rather
than letting this network-level efficiency issue distort the structure
of the programmer's interface. Thus if the user calls several access
functions, without calling any other CLX interfaces in between, the first
access function call does an X request to get a batch of values, waits for
the reply, saves the resulting bundle of values behind the scenes, and
returns the one desired value. The following access function calls quickly
get their values from that behind-the-scenes cache. The next X request
transmitted purges the cache.
(4) Synchronization, because it is necessary to set a bunch of values in
a single atomic operation, or to get a bunch of values that form a consistent
set. I don't know whether this is a real issue. If it is, it might be
handled by a combination of two approaches: wrap a higher level locking
operation around the sequence of calls to access functions; for common
cases where a few values must be read or written as an atomic operation,
provide a special case function that accesses just those few values.
∂15-Apr-87 0701 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU keyword args and consing
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 07:01:19 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Apr 87 09:59-EDT
Date: Wed, 15 Apr 87 10:03 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: keyword args and consing
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12294544961.BABYL@C.CS.CMU.EDU>
Message-ID: <870415100313.3.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 14 Apr 1987 19:12 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
In our implementation (and probably many others) keyword args are implemented
using rest args, so they cons. I believe that there are something like 11
fields in the event you get for a key being pressed event. 11 * 2 * 8 = 176
bytes consed for every call with those event keywords. At least at first
glance it also looked like these keys might be passed to more than one call for
each event, introducing another factor of two or so. Even if you never
explicitly reclaim event structures you will cons four times less using a
structure.
Some real facts! Your concerns were far from obvious until now.
However, I would like to know how many other implementations suffer from
this "feature", before we redesign lots of things.
∂15-Apr-87 0734 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU XCL [sic] comments
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 07:33:57 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Apr 87 10:31-EDT
Date: Wed, 15 Apr 87 10:35 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: XCL [sic] comments
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12294544961.BABYL@C.CS.CMU.EDU>
Message-ID: <870415103529.6.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 14 Apr 1987 19:12 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Explicit Using a structure to represent events also cleans
up the interface to the SEND-EVENT functions, since we don't have
to pass in the components using &ALLOW-OTHER-KEYS.
Perhaps this is just personal taste; having to cons up a structure only to
have it torn down again doesn't seem particularly cleaner to me.
Well, I don't really know how those functions are used, but I was guessing
that they were often used to relay an event that you read from somewhere,
rather than shoving in events that you created.
SEND-EVENT typically won't be used much at all, and I expect will almost always
be a newly created event rather that a forwarding of some existing event. I
agree that if NEXT-EVENT were changed to use structures, that SEND-EVENT should
be changed to match.
I agree that [timeout in next-event]
may be ugly to implement in some cases, but it also very useful. One of
the routine hassles in porting Hemlock is figuring out some way to
implement EDITOR-SLEEP, which is like sleep, but is defined to return when
input is available.
I would like to hear opinions from others about this matter. Sticking a
timeout in next-event isn't a complete solution; an application might just
as easily want to wait for a more general OR of conditions than "X event
or timeout". Your wait-for-event is just a particular example of munging
together a particular set of conditions.
I also think it is worth specifying a simple event
interface using CLOS. [...]
What does this really mean? Are you proposing this on top of the
existing interface, or within it, or instead of?
I guess within it, since it might be awkward to implement it on top of
next-event. I don't have any problem with providing direct access to the
event stream, but I think that you badly need some kind of automatic
demultiplexing mechanism for even simple applications.
I agree that more automatic mechanisms are needed, but I disagree that they
should be defined at this level (partly because I think agreement will
be difficult to obtain). Someone could/should certainly propose a CLOS
object-oriented layer to put on top of CLX, and include in it an automatic
event distribution mechanism that replaces the CLX event functions (in the
sense that the CLX ones should not be called directly). Again, opinions
from others would be useful.
∂15-Apr-87 0809 larus@paris.Berkeley.EDU Re: keyword args and consing
Received: from [128.32.150.46] by SAIL.STANFORD.EDU with TCP; 15 Apr 87 08:09:50 PDT
Received: by paris.Berkeley.EDU (3.2/1.22)
id AA03670; Wed, 15 Apr 87 08:10:22 PDT
From: larus@paris.Berkeley.EDU (James Larus)
Message-Id: <8704151510.AA03670@paris.Berkeley.EDU>
To: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Cc: RAM@c.cs.cmu.edu, cl-windows@sail.stanford.edu
Subject: Re: keyword args and consing
In-Reply-To: Your message of Wed, 15 Apr 87 10:03:00 EDT.
<870415100313.3.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 15 Apr 87 08:10:18 PDT
This "feature" of Spice Lisp is taking Lisp Machine envy too far.
On systems without cdr-coding, there is no good reason to build &rest
args to parse keywords. We changed SPUR Lisp (a Spice Lisp port) to
scan the arguments with a lexpr-like convention and got a noticable
improvement in speed and reduced garbage. I believe that Excl does
not cons &key arguments either, but you should check with jkf.
/Jim
∂15-Apr-87 0831 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU plist revisions to CLX proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 08:31:33 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Apr 87 11:29-EDT
Date: Wed, 15 Apr 87 11:33 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: plist revisions to CLX proposal
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870415004116.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870415113324.0.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 15 Apr 87 00:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
(1) Tastefulness. I think the discussion of many alternative ways
of getting the multiple values, all of which are ugly and many of
which are inefficient, has discredited this.
I have a revised proposal, seen by Moon and a few others, which
provides both structure and subset multiple-value returns, and
no macro interfaces, which I now rather like. I will forward it
to the whole list in a separate message.
(2) Efficiency, because function calling is too slow.
No, this isn't a concern to me.
(3) Efficiency, because the X protocol wants to batch up the reads
or writes into a single request. In my opinion, this would be better
handled by caching (for reads) and buffering (for writes), rather
than letting this network-level efficiency issue distort the structure
of the programmer's interface.
There is a trade-off between implementation complexity/cost and
interface complexity/cost; it isn't clear the functions in question will
be used often enough to justify a complex implementation or an optimal
interface. Individual accessors make sense for window-attributes,
drawable-geometry, and keyboard-control; they make less sense for
text-extents, and very little sense for query-pointer. Also, as I tried
to indicate with the subset multiple-value functions I sent out, the
caller is very likely to want more than one value at a time, which makes
individual accessors less convenient to use, and certainly a pain if you
really want everything.
(4) Synchronization, because it is necessary to set a bunch of values in
a single atomic operation, or to get a bunch of values that form a consistent
set. I don't know whether this is a real issue. If it is, it might be
handled by a combination of two approaches: wrap a higher level locking
operation around the sequence of calls to access functions; for common
cases where a few values must be read or written as an atomic operation,
provide a special case function that accesses just those few values.
This is the real issue. Requiring higher-level locking means using
with-server-grabbed, not with-display, because there will generally be
non-local clients as well. Moreover, no amount of synchronization will
help for query-pointer, since you can't lock the user. I find
higher-level locking even uglier solution, since it make it easier to
forget (leading to bugs), and requires an overkill of synchronization to
get back a semantics that was thrown away.
∂15-Apr-87 0834 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU another try at CLX "lots of result values"
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 08:34:21 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Apr 87 11:32-EDT
Date: Wed, 15 Apr 87 11:36 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: another try at CLX "lots of result values"
To: cl-windows@sail.stanford.edu
Message-ID: <870415113622.1.RWS@KILLINGTON.LCS.MIT.EDU>
I've followed the suggestion of defining structures for the
values, allowing an optional structure to be passed in to
avoid consing, defining various subset returning functions,
and eliminating the macro forms entirely.
Is the use of both &optional and &key in text-extents acceptable?
Should just that one be changed to &key, or would it be better to
pass the structure by keyword in all cases instead?
(defstruct window-attributes
(visual <unspec> :type integer)
(class <unspec> :type (member :input-output :input-only))
(bit-gravity <unspec> :type bit-gravity)
(win-gravity <unspec> :type win-gravity)
(backing-store <unspec> :type (member :not-useful :when-mapped :always))
(backing-bit-planes <unspec> :type integer)
(backing-pixel <unspec> :type integer)
(save-under <unspec> :type (member :on :off))
(colormap <unspec> :type (or null colormap))
(colormap-installed-p <unspec> :type boolean)
(map-state <unspec> :type (member :unmapped :unviewable :viewable))
(all-event-masks <unspec> :type integer)
(event-mask <unspec> :type integer)
(do-not-propagate-mask <unspec> :type integer)
(override-redirect <unspec> :type (member :on :off)))
(defun window-attributes (window &optional attributes)
(declare (type window window)
(type (or null window-attributes) attributes)
(values window-attributes)))
(defun window-kind (window)
;; Needs a better name?
(declare (type window window)
(values visual class)))
(defun window-gravity (window)
(declare (type window window)
(values bit-gravity win-gravity)))
(defun window-backing-store (window)
(declare (type window window)
(values backing-store save-under backing-bit-planes backing-pixel)))
(defun window-colormap (window)
(declare (type window window)
(values colormap colormap-installed-p)))
(defun window-map-state (window)
(declare (type window window)
(values map-state)))
(defun window-event-masks (window)
(declare (type window window)
(values event-mask all-event-masks do-not-propagate-mask override-redirect)))
(defstruct drawable-geometry
(root <unspec> :type window)
(depth <unspec> :type integer)
(x <unspec> :type integer)
(y <unspec> :type integer)
;; Width and height are the inside size, excluding border.
(width <unspec> :type integer)
(height <unspec> :type integer)
(border-width <unspec> :type integer))
(defun drawable-geometry (drawable &optional geometry)
(declare (type drawable drawable)
(type (or null drawable-geometry) geometry)
(values drawable-geometry)))
(defun drawable-size (drawable)
;; Width and height are the inside size, excluding border.
(declare (type drawable drawable)
(values width height border-width)))
(defun drawable-rectangle (drawable)
;; Width and height are the outside size, including border.
(declare (type drawable drawable)
(values x y width height border-width)))
(defun drawable-depth (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-root (drawable)
(declare (type drawable drawable)
(values window)))
(defstruct pointer-info
(x <unspec> :type integer)
(y <unspec> :type integer)
(mask <unspec> :type integer)
(root <unspec> :type window)
(child <unspec> :type (or null window))
(same-screen-p <unspec> :type boolean)
(root-x <unspec> :type integer)
(root-y <unspec> :type integer))
(defun query-pointer (window &optional info)
(declare (type window window)
(type (or null pointer-info) info)
(values pointer-info)))
(defun pointer-position (window)
(declare (type window window)
(values x y same-screen-p)))
(defun global-pointer-position (display)
(declare (type display display)
(values root root-x root-y)))
(defstruct text-extents
(direction <unspec> :type draw-direction)
(font-ascent <unspec> :type integer)
(font-descent <unspec> :type integer)
(ascent <unspec> :type integer)
(descent <unspec> :type integer)
(width <unspec> :type integer)
(left <unspec> :type integer)
(right <unspec> :type integer))
(defun text-extents (font string &optional extents &key (cache-p t))
;; If no font info is cached locally, and cache-p is nil, this uses the protocol request.
;; Otherwise, the font info is obtained if necessary, and then the result is computed
;; locally.
(declare (type (or font gc) font)
(type string string)
(type (or null text-extents) extents)
(type boolean cache-p)
(values text-extents)))
(defun text-bounds (font string &key (cache-p t))
;; If no font info is cached locally, and cache-p is nil, this uses the protocol request.
;; Otherwise, the font info is obtained if necessary, and then the result is computed
;; locally.
(declare (type (or font gc) font)
(type string string)
(type boolean cache-p)
(values width ascent descent left right)))
(defun text-width (font string &key (cache-p t))
;; If no font info is cached locally, and cache-p is nil, this uses the protocol request.
;; Otherwise, the font info is obtained if necessary, and then the result is computed
;; locally.
(declare (type (or font gc) font)
(type string string)
(type boolean cache-p)
(values integer)))
(defstruct keyboard-control
(key-click-percent <unspec> :type integer)
(bell-percent <unspec> :type integer)
(bell-pitch <unspec> :type integer)
(bell-duration <unspec> :type integer)
(led-mask <unspec> :type integer)
(global-auto-repeat <unspec> :type (member :on :off))
(auto-repeats <unspec> :type (bit-vector 256)))
(defun keyboard-control (display &optional control)
(declare (type display display)
(type (or null keyboard-control) control)
(values keyboard-control)))
∂15-Apr-87 0901 FAHLMAN@C.CS.CMU.EDU keyword args and consing
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 09:01:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Apr 87 11:49:16-EDT
Date: Wed, 15 Apr 1987 11:49 EDT
Message-ID: <FAHLMAN.12294726379.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: keyword args and consing
In-reply-to: Msg of 15 Apr 1987 10:03-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Your concerns were far from obvious until now.
However, I would like to know how many other implementations suffer from
this "feature", [keyword args do lots of consing] before we redesign
lots of things.
I think you will find that the overwhelming majority of Common Lisp
implementations build &key arguments on top of the &rest mechanism, and
that almost all implementations on stock hardware cons up the rest-arg
list (except for certain built-in &rest and &key functions, which the
compiler special-cases). In many of these systems, the documentation
warns users not to use keywrod args in tense inner loops, precisely
because they cons.
Since it is important that CLX run on stock hardware, I would advise
against using keyword args in functions that are likely to be
inner-loop. Since CLX must be somewhat implementation-dependent, it
would be possible for each implementation to fix up its compiler to
special-case the necessary forms, but avoiding this hassle would be
nice.
It is technically possible for the compiler to do the necessary analysis
to verify that a &rest arg is used only within the current dynamic
context, and to do stack-consing in those cases where it is legal. I
don't know of any commercially available Common Lisp compiler that does
this at present.
The Symbolics and, I think, TI Common Lisp implementations did
stack-consing of &rest args without the benefit of such analsysis,
violating the Common Lisp standard and producing some bugs of incredible
subtlety; apparently they felt that the performance gain was worth the
hassle. I believe that Symbolics intends to put the analsysis in and to
come into compliance with the standard that way; I don't know if this
has yet been released by Symbolics, or what TI's plans are.
I am in the process of proposing a new mechanism, &more, that might help
to eliminate most of this consing, but it might be a tough fight to get
this adopted -- nobody is eager to see another Lambda-list keyword.
-- Scott
∂15-Apr-87 1038 Moon@STONY-BROOK.SCRC.Symbolics.COM keyword args and consing
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Apr 87 10:37:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 116649; Wed 15-Apr-87 13:37:21 EDT
Date: Wed, 15 Apr 87 13:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: keyword args and consing
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12294726379.BABYL@C.CS.CMU.EDU>
Message-ID: <870415133655.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Apr 1987 11:49 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
However, I would like to know how many other implementations suffer from
this "feature", [keyword args do lots of consing] before we redesign
lots of things.
I think you will find that the overwhelming majority of Common Lisp
implementations build &key arguments on top of the &rest mechanism, and
that almost all implementations on stock hardware cons up the rest-arg
list (except for certain built-in &rest and &key functions, which the
compiler special-cases). In many of these systems, the documentation
warns users not to use keywrod args in tense inner loops, precisely
because they cons.
Since it is important that CLX run on stock hardware, I would advise
against using keyword args in functions that are likely to be
inner-loop. Since CLX must be somewhat implementation-dependent, it
would be possible for each implementation to fix up its compiler to
special-case the necessary forms, but avoiding this hassle would be
nice.
I find it difficult to believe that there are any serious implementations of
Common Lisp in which it is impossible for the CLX porter to add compiler
optimizers to eliminate this consing for the things that are called often
enough that it matters. It simply means making a non-keyword-taking version
of the function and writing a compiler optimizer (called a compiler macro
in some systems) that transforms a call to one into a call to the other.
This has to be ten times as easy as putting in the implementation-dependent
interface to the network, or other communication path to the X server, and
making that adequately efficient.
Another point is that if X and Common Lisp are each as successful as it
currently appears they are going to be, the lifetime of this CLX interface
will be far longer than the lifetimes of the particular implementation
versions that have inefficient keyword arguments. After all, it's not
impossibly difficult to do keyword arguments without consing, and the
only reason some implementations have not done that yet is that their
implementors have had more important tasks to see to.
Thus I really don't think it's appropriate to warp the whole design to
compensate for a minor flaw in current versions of a small number of
Common Lisp implementations.
∂15-Apr-87 1116 RAM@C.CS.CMU.EDU keyword args and consing
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 11:16:02 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 15 Apr 87 14:09:59-EDT
Date: Wed, 15 Apr 1987 14:09 EDT
Message-ID: <RAM.12294751996.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-windows@SAIL.STANFORD.EDU, "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>,
Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: keyword args and consing
In-reply-to: Msg of 15 Apr 1987 13:36-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
We already do the optimization of transforming keyword calls to known
functions into non-keyword versions. The problem is that in the event
interface, the functions are user supplied funargs rather than known
named function; in this case such a transformation is not possible.
Rob
∂15-Apr-87 1629 MMcM@YUKON.SCRC.Symbolics.COM XCL [sic] comments
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 15 Apr 87 16:29:34 PDT
Received: from OWL.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 194271; Wed 15-Apr-87 19:09:52 EDT
Date: Wed, 15 Apr 87 19:09 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: XCL [sic] comments
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: RAM@C.CS.CMU.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870415103529.6.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870415190932.1.MMCM@OWL.SCRC.Symbolics.COM>
Date: Wed, 15 Apr 87 10:35 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Date: Tue, 14 Apr 1987 19:12 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
I guess within it, since it might be awkward to implement it on top of
next-event. I don't have any problem with providing direct access to the
event stream, but I think that you badly need some kind of automatic
demultiplexing mechanism for even simple applications.
I agree that more automatic mechanisms are needed, but I disagree that they
should be defined at this level (partly because I think agreement will
be difficult to obtain). Someone could/should certainly propose a CLOS
object-oriented layer to put on top of CLX, and include in it an automatic
event distribution mechanism that replaces the CLX event functions (in the
sense that the CLX ones should not be called directly). Again, opinions
from others would be useful.
I frankly don't see the problem with implementing a function to be given
to next-event which takes event code (a keyword) and uses it to get a
generic function which is then applied to the window argument and other
arguments.
If consing of the rest arg is an issue, then the implementation can
supply a version of event-case which works directly off of event
structures as maintained by the lower levels. The dispatching for
window functions is then done inline in a single use of this macro. A
good enough version of this macro could even directly index the
functions from the event indices.
The real issue to my mind is whether we wish to standardize on the
demultiplexing mechanism as part of this layer. I don't think so, since
as everyone points out, it's logically part of a higher level.
Furthermore, my own prejudice in implementing a higher level window
system would not be to pass events to window objects as the first in the
chain of command.
∂15-Apr-87 1854 edsel!bhopal!jonl@navajo.stanford.edu keyword args and consing
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 18:54:21 PDT
Received: by navajo.stanford.edu; Wed, 15 Apr 87 18:53:41 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA28250; Wed, 15 Apr 87 17:40:57 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA09310; Wed, 15 Apr 87 18:37:57 PDT
Date: Wed, 15 Apr 87 18:37:57 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704160137.AA09310@bhopal.edsel.com>
To: navajo!Fahlman%C.CS.CMU.EDU@navajo.stanford.edu
Cc: navajo!RWS%ZERMATT.LCS.MIT.EDU@navajo.stanford.edu,
navajo!cl-windows%SAIL@navajo.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Wed, 15 Apr 1987 11:49 EDT
Subject: keyword args and consing
Re: I think you will find that the overwhelming majority of Common Lisp
implementations build &key arguments on top of the &rest mechanism, ...
Oh, really? Who all are you including? Lucid Common Lisp certainly doesn't
use &rest, or any other consy means, to spread out the &key args. Probably
EXcL and VAXLISP don't either. Anyone know?
-- JonL --
∂15-Apr-87 1936 FAHLMAN@C.CS.CMU.EDU Consing &key args
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 19:36:31 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Apr 87 22:37:27-EDT
Date: Wed, 15 Apr 1987 22:37 EDT
Message-ID: <FAHLMAN.12294844399.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-windows@SAIL.STANFORD.EDU
Subject: Consing &key args
I was indeed counting Lucid's implementation among those that consed
&key args. I stand corrected.
-- Scott
∂16-Apr-87 0857 Oren%Tilde%ti-csl.csnet@RELAY.CS.NET Re: plist revisions to CLX proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Apr 87 08:57:36 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab13828; 16 Apr 87 11:51 EDT
Received: from ti-csl by RELAY.CS.NET id ab15028; 16 Apr 87 11:46 AST
Received: from SI (si.ARPA) by tilde id AA01943; Wed, 15 Apr 87 17:01:34 cdt
Message-Id: <2754514800-12044628@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 15 Apr 87 18:00:00 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: clx@ZERMATT.LCS.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
Subject: Re: plist revisions to CLX proposal
In-Reply-To: Msg of Wed, 15 Apr 87 00:41 EDT from "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
> The more natural interface, I think, would be to provide a separate
> access function for each value. If the user wants to get several
> values, he can call several access functions. SETF of the access
> functions works nicely for altering values.
I agree! Accessor functions are clearly the most efficient, cleanest
way to get at the large number of values returned by the
GetWindowAttributes, GetGeometry, QueryPointer, QueryTextExtents and
GetKeyBoardControl server requests. Its nice to have a consistent
paradigm of structures with accessors allowing SETF. This also
eliminates the need for redundant accessor functions like
drawable-geometry, drawable-size and drawable-rectangle.
- LaMott
∂16-Apr-87 0944 lowry%bizet.DEC@decwrl.DEC.COM X interface
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 09:44:08 PDT
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA01254; Thu, 16 Apr 87 08:44:54 PST
Message-Id: <8704161644.AA01254@decwrl.dec.com>
Date: Thursday, 16 Apr 1987 09:25:25-PDT
From: lowry%bizet.DEC@decwrl.DEC.COM (David Lowry 225-6290)
To: cl-windows@sail.stanford.edu
Subject: X interface
VAXLISP doesn't cons up &keys either.
Here is what is going on at DEC. VAXLISP V2.2 goes to field test soon.
In the Ultrix version, we are shipping an XLIB interface written using
the VAXLISP callout facility, our way of calling foreign functions.
This allows us to access the functions in the /usr/lib/libX.c library
directly from Lisp. We implement X structures using the VAXLISP
alien-structure mechanism, so we can read them in lisp the same as CL
structures, and pass them to the X interface. If X creates a structure
and passes it back, we don't copy it into Lisp memory. However structures
we pass that X fills in (such as events) are created in Lisp memory.
Our basic strategy has been to supply the Lisp equivalent of the
C version of the X functions. We provide as little extra functionality
as we can, mostly creating and passing the alien-structures that X fills
in, and some help functions for problems between the Lisp and C version,
such as making vertices for the DRAW functions.
This is for X10. We are shipping the source code for the X
callouts with VAXLISP. We haven't decided yet how we will implement X11.
I will certainly keep up on the CLX proposals, but the decision will be
based on those and other considerations.
David Lowry
DEC
∂16-Apr-87 1041 ibuki!weaver@labrea.stanford.edu Re: keyword args and consing
Received: from LABREA by SAIL.STANFORD.EDU with TCP; 16 Apr 87 10:41:14 PDT
Received: by labrea.stanford.edu; Thu, 16 Apr 87 10:41:51 PST
Received: by ibuki.UUCP (1.4/4.7)
id AA6619220; Thu, 16 Apr 87 10:34:16 pst
Date: Thu, 16 Apr 87 10:34:16 pst
From: ibuki!weaver@labrea.stanford.edu (Eric Weaver)
Message-Id: <8704161834.AA6619220@ibuki.UUCP>
To: labrea!cl-windows@sail.arpa
Subject: Re: keyword args and consing
Date: Wed, 15 Apr 87 18:37:57 PDT
From: labrea!edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Re: I think you will find that the overwhelming majority of Common Lisp
implementations build &key arguments on top of the &rest mechanism, ...
Oh, really? Who all are you including? Lucid Common Lisp certainly doesn't
use &rest, or any other consy means, to spread out the &key args. Probably
EXcL and VAXLISP don't either. Anyone know?
-- JonL --
KCL doesn't; it just looks at what's on the stack.
∂17-Apr-87 0820 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU minor correction to CLX event-case
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 08:20:18 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Apr 87 11:20-EDT
Date: Fri, 17 Apr 87 11:22 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: minor correction to CLX event-case
To: cl-windows@sail.stanford.edu
Message-ID: <870417112200.7.RWS@KILLINGTON.LCS.MIT.EDU>
The proposed EVENT-CASE macro form failed to allow T or
OTHERWISE in place of the event-or-events specifier.
Clearly this should be allowed (in the last clause).
Also, if no t/otherwise clause appears, it should be
equivalent to having one that returns nil.
∂22-Apr-87 0551 RWS@ZERMATT.LCS.MIT.EDU WITH-GC semantics in CLX
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Apr 87 05:51:07 PDT
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 45520; Wed 22-Apr-87 08:52:59 EDT
Date: Wed, 22 Apr 87 08:52 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: WITH-GC semantics in CLX
To: cl-windows@sail.stanford.edu
Message-ID: <870422085258.6.RWS@KILLINGTON.LCS.MIT.EDU>
The initial CLX proposal stated that WITH-GC locked the graphics context
in a multi-process system. This means that all of the drawing functions
must also lock GCs. Not only is this a potential performance hit, but
it introduces the possibility of deadlock.
We are revising the specification, to state that WITH-GC changes and
restores the graphics context in such a way that the changes have
dynamic scope (i.e., indefinite scope and dynamic extent) and are
per-process in a multi-process environment. No "locking" is performed
(although a multi-process implementation will certainly make use of the
underlying with-display locking inherent in each graphics operation in
order to make the server-stored state consistent with the per-process
logical state).
∂22-Apr-87 2012 Moon@STONY-BROOK.SCRC.Symbolics.COM another try at CLX "lots of result values"
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Apr 87 20:12:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 122432; Wed 22-Apr-87 23:11:42 EDT
Date: Wed, 22 Apr 87 23:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: another try at CLX "lots of result values"
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870415113622.1.RWS@KILLINGTON.LCS.MIT.EDU>,
<870415113324.0.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870422231121.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is not a transcendently important issue, but even so I'd like to open it
one more time. The better this standard fits into the rest of Common Lisp the
more success people will have in using it, I feel.
Date: Wed, 15 Apr 87 11:36 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
I've followed the suggestion of defining structures for the
values, allowing an optional structure to be passed in to
avoid consing, defining various subset returning functions,
and eliminating the macro forms entirely.
(Eliminating the macro forms is certainly good. The ones I suggested
were a totally bad idea!)
This will work, but this indirection through structures still doesn't seem
right to me. For example, in Common Lisp style I would expect to be able
to say
(window-bit-gravity window)
to obtain the bit-gravity of a window, but instead I have to say
(window-attributes-bit-gravity (window-attributes window))
It's worse if I want to change it. Instead of
(setf (window-bit-gravity window) value)
I have to say [I'm guessing here, because you didn't show how to do
this at all in your message]
(let ((wa (window-attributes window)))
(setf (window-attributes-bit-gravity wa) value)
(set-window-attributes window wa))
and what if I forget and write
(setf (window-attributes-bit-gravity (window-attributes window)) value)
This compiles and runs, but doesn't have any effect on the window.
It really seems like I'm doing a lot of manual storage management
with these structures, as if I was programming in C instead of Lisp.
I think the subset-returning functions you added to try to fix this actually
make the situation worse, because now there are two ways to access some data,
but only one way to access other data, things are less consistent, and the
programmer might have to spend a lot more time with his nose buried in a
manual.
I think the fields of windows, drawables, and keyboards are fundamentally
different from text-extents and query-pointer, and trying to fit all of these
into the same mold is part of the problem. The window, drawable, and keyboard
fields are conceptually the same as defstruct slots, except that the storage
resides in the server machine, not in Lisp memory. One would expect to be
able to manipulate them with the same accessor-and-setf syntax that is used
for defstruct slots. Furthermore, as far as I can tell, there are no
synchronization nor efficiency issues that would necessitate special ways to
read and write more than one field at a time. So I really feel that this
group ought to follow the single-field accessor model rather than the
return-a-structure model.
Text-extents and query-pointer are different. These values are not "fields"
that one could imagine changing with setf. As you pointed to me, the values
from query-pointer are instantaneous values that must be read as a group to be
meaningful. Text-extents doesn't seem to have a synchronization issue, but
the values still aren't useful individually. The only choices that make sense
for these two are to return a structure or to return multiple values. The
first approach has the advantage of using names instead of positions, but
involves more conceptual baggage, and has some risk of an efficiency cost. I
would personally opt for the second approach, because you are only returning
eight values and I think that number is manageable. But
text-extent/query-pointer are less clear-cut than the first three.
Two minor comments:
Is the use of both &optional and &key in text-extents acceptable?
It is almost always asking for trouble to use &optional and &key in
the same parameter list.
Date: Wed, 15 Apr 87 11:33 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
the caller is very likely to want more than one value at a time, which makes
individual accessors less convenient to use, and certainly a pain if you
really want everything.
I don't buy this. Is
(logxor (window-event-mask window) (window-do-not-propagate-mask window))
really less convenient than
(let ((wa (window-attributes window)))
(logxor (window-attributes-event-mask wa)
(window-attributes-do-not-propagate-mask wa)))
(The example is made-up and doesn't make sense semantically; that's not
important.)
∂23-Apr-87 0953 Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET Re: another try at CLX "lots of result values"
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Apr 87 09:53:37 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae17052; 23 Apr 87 12:53 EDT
Received: from ti-csl by RELAY.CS.NET id ag07248; 23 Apr 87 12:45 AST
Received: from dsg (juliett.ARPA) by tilde id AA24479; Thu, 23 Apr 87 11:45:00 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 23 Apr 87 11:46:02 CDT
Message-Id: <2755183534-3649459@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Thu, 23 Apr 87 11:45:34 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: another try at CLX "lots of result values"
In-Reply-To: Msg of Wed, 22 Apr 87 23:11 EDT from "David A. Moon" <Moon@scrc-stony-brook.arpa>
I appreciate your point concerning the importance of a smooth fit between CLX
and the Common Lisp way of life. So, I'm inclined to favor the single-field
accessor model which you propose. However, there is one snag which bothers me,
and that's the idea of individually SETF'ing the fields of a window, etc. The
implication seems to be that CLX should generate a server request for each SETF
operation. I don't see how CLX could batch these requests reliably, without
exposing the caching mechanism in its interfaces, and yet I detect an aversion
to interfaces that make control of a cache explicit. Now, I'm convinced that
updating several window attributes at a "whack" will be a common and useful X
operation. So, I'm reluctant to see an approach that will make this operation
unnecessarily costly.
All of the issues and alternatives here have been thoroughly discussed. My only
contribution to the debate is the following bit of philosophy: that the client
and the server are in different address spaces is a fundamental fact of X
reality, and any CLX model that "pretends" that this is not so is probably a
mistake. Specifically, the single-field accessor model tries to cover up this
fundamental fact, and while it may be possible for CLX to jump through its own
earlobe trying to preserve such a model, it's probably not worth it.
To me, Scheifler's latest proposal, based on defstructs, strikes the best
balance between ease-of-use and efficiency of implementation, in a model that
recognizes the reality of network packets in an undistorted fashion.
∂23-Apr-87 1139 Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET Re: another try at CLX "lots of result values"
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Apr 87 09:53:37 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae17052; 23 Apr 87 12:53 EDT
Received: from ti-csl by RELAY.CS.NET id ag07248; 23 Apr 87 12:45 AST
Received: from dsg (juliett.ARPA) by tilde id AA24479; Thu, 23 Apr 87 11:45:00 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 23 Apr 87 11:46:02 CDT
Message-Id: <2755183534-3649459@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Thu, 23 Apr 87 11:45:34 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: another try at CLX "lots of result values"
In-Reply-To: Msg of Wed, 22 Apr 87 23:11 EDT from "David A. Moon" <Moon@scrc-stony-brook.arpa>
I appreciate your point concerning the importance of a smooth fit between CLX
and the Common Lisp way of life. So, I'm inclined to favor the single-field
accessor model which you propose. However, there is one snag which bothers me,
and that's the idea of individually SETF'ing the fields of a window, etc. The
implication seems to be that CLX should generate a server request for each SETF
operation. I don't see how CLX could batch these requests reliably, without
exposing the caching mechanism in its interfaces, and yet I detect an aversion
to interfaces that make control of a cache explicit. Now, I'm convinced that
updating several window attributes at a "whack" will be a common and useful X
operation. So, I'm reluctant to see an approach that will make this operation
unnecessarily costly.
All of the issues and alternatives here have been thoroughly discussed. My only
contribution to the debate is the following bit of philosophy: that the client
and the server are in different address spaces is a fundamental fact of X
reality, and any CLX model that "pretends" that this is not so is probably a
mistake. Specifically, the single-field accessor model tries to cover up this
fundamental fact, and while it may be possible for CLX to jump through its own
earlobe trying to preserve such a model, it's probably not worth it.
To me, Scheifler's latest proposal, based on defstructs, strikes the best
balance between ease-of-use and efficiency of implementation, in a model that
recognizes the reality of network packets in an undistorted fashion.
∂23-Apr-87 1513 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: another try at CLX "lots of result values"
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 15:13:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123345; Thu 23-Apr-87 18:11:47 EDT
Date: Thu, 23 Apr 87 18:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: another try at CLX "lots of result values"
To: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>, DDYER@RIVERSIDE.SCRC.Symbolics.COM
cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2755183534-3649459@Sierra>,
<870423115325.8.DDYER@PURPLE.SWW.Symbolics.COM>
Message-ID: <870423181134.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I guess the conversation between RWS and me in which it was determined
that efficiency was not an issue was not sent to the whole mailing list.
Here "efficiency" means batching of multiple field accesses into a
single server request. RWS doesn't think this will happen often enough
to be an issue. I think that it is straightforward and simple to
complexify the implementation so that it can do this batching, without
having to complicate the interface. Either way, the design of the
interface need not be affected by this efficiency consideration.
(Incidentally, unless I am confused the proposed interface already
requires this sort of complexification for graphics contexts.)
∂23-Apr-87 1521 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU another try at CLX "lots of result values"
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 15:20:58 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 23 Apr 87 18:19-EDT
Date: Thu, 23 Apr 87 18:22 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: another try at CLX "lots of result values"
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870422231121.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870423182233.4.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 22 Apr 87 23:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
For example, in Common Lisp style I would expect to be able
to say
(window-bit-gravity window)
to obtain the bit-gravity of a window, but instead I have to say
(window-attributes-bit-gravity (window-attributes window))
Actually, this particular case is just (window-gravity window), but
yes, I have arbitrarily chosen to clump things into a few subsets
and provide multiple-value functions (in addition to the general
structure returning function), rather than (also) providing all of
the individual accessors.
It's worse if I want to change it. Instead of
(setf (window-bit-gravity window) value)
I have to say [I'm guessing here, because you didn't show how to do
this at all in your message]
(let ((wa (window-attributes window)))
(setf (window-attributes-bit-gravity wa) value)
(set-window-attributes window wa))
Changing things is with (change-window-attributes window :bit-gravity value)
as specified in the original proposal, rather than (also) having individual setfs.
There is no need to use the structure forms except when you want to get all of
the information out indivisibly.
If people REALLY want all of the individual accessors and setfs, they can certainly
be provided (whether as part of the base proposal or implemented on top). I don't
particularly care, provided they are not the ONLY mechanism.
I think the subset-returning functions you added to try to fix this actually
make the situation worse, because now there are two ways to access some data,
but only one way to access other data, things are less consistent, and the
programmer might have to spend a lot more time with his nose buried in a
manual.
I disagree. I don't see this as any worse than the fact that Genera, for example,
has :position and :edges as well as :x-offset and :y-offset and :height and :width
and :inside-size and ... You try and provide interfaces for common cases.
The window, drawable, and keyboard
fields are conceptually the same as defstruct slots, except that the storage
resides in the server machine, not in Lisp memory. One would expect to be
able to manipulate them with the same accessor-and-setf syntax that is used
for defstruct slots. Furthermore, as far as I can tell, there are no
synchronization nor efficiency issues that would necessitate special ways to
read and write more than one field at a time.
Round-trip times are an efficiency issue, and getting consistent values is a
synchronization issue.
Text-extents and query-pointer are different.
The only choices that make sense
for these two are to return a structure or to return multiple values. The
first approach has the advantage of using names instead of positions, but
involves more conceptual baggage, and has some risk of an efficiency cost. I
would personally opt for the second approach, because you are only returning
eight values and I think that number is manageable.
I don't particularly care about these. If people would prefer getting rid of
their structure forms and having just one (or more) multiple-value form, that
would be fine with me.
Is the use of both &optional and &key in text-extents acceptable?
It is almost always asking for trouble to use &optional and &key in
the same parameter list.
I agree. The only question is how to change it. Should they both be
optional, or both keyword? Related to this, one person has suggested
that all functions with a singleton &key be changed to have an &optional
instead. I would like to hear opinions from others.
∂23-Apr-87 1547 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: another try at CLX "lots of result values"
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 15:47:05 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 23 Apr 87 18:42-EDT
Date: Thu, 23 Apr 87 18:46 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: another try at CLX "lots of result values"
To: Moon@STONY-BROOK.SCRC.Symbolics.COM,
Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET,
DDYER@RIVERSIDE.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870423181134.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870423184609.7.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 23 Apr 87 18:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Here "efficiency" means batching of multiple field accesses into a
single server request. RWS doesn't think this will happen often enough
to be an issue. I think that it is straightforward and simple to
complexify the implementation so that it can do this batching, without
having to complicate the interface. Either way, the design of the
interface need not be affected by this efficiency consideration.
Yes (although I may have just indicated to the contrary in a previous
message), I don't think the window/drawable/keyboard requests are
important from a performance point of view, although synchronization
when reading and writing is important. Basically, I don't think they
are important enough that "natural" interfaces are important; simplicity
(while worrying about synchronization) seems most important. To me,
this argues against accessor/setf as the only mechanism, and two sets of
mechanism are overkill.
(Incidentally, unless I am confused the proposed interface already
requires this sort of complexification for graphics contexts.)
Graphics contexts are a critical part of normal operation; dynamic
binding and caching and the implied complexity are well worth the effort
here. Also, graphics contexts are NOT intended to be shared by clients
under normal circumstances, so local caching strategies are perfectly
reasonable.
∂23-Apr-87 2102 dcmartin@postgres Re: another try at CLX "lots of result values"
Received: from [128.32.149.1] by SAIL.STANFORD.EDU with TCP; 23 Apr 87 21:02:27 PDT
Received: by postgres (3.2/1.22)
id AA17962; Thu, 23 Apr 87 21:02:22 PDT
Message-Id: <8704240402.AA17962@postgres>
From: David C. Martin <dcmartin@postgres>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Cc: Moon@stony-brook.scrc.symbolics.com, cl-windows@sail.stanford.edu
Precedence: special-delivery
In-Reply-To: Your message of Thu, 23 Apr 87 18:22 EDT
<870423182233.4.RWS@KILLINGTON.LCS.MIT.EDU>
Subject: Re: another try at CLX "lots of result values"
Date: Thu, 23 Apr 87 21:02:20 PDT
Sender: dcmartin@postgres
Your letter:
I agree. The only question is how to change it. Should they both be
optional, or both keyword? Related to this, one person has suggested
that all functions with a singleton &key be changed to have an &optional
instead. I would like to hear opinions from others.
In implementing XCL (not CLX, mind you :-), I found that most of the people
implementing code using the interface preferred to have singleton keywords
as optionals. I have also found this to be the case considering the plethora
of functions and my forgetfulness.
dcm
∂23-Apr-87 2139 Moon@STONY-BROOK.SCRC.Symbolics.COM another try at CLX "lots of result values"
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 21:39:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123683; Fri 24-Apr-87 00:39:10 EDT
Date: Fri, 24 Apr 87 00:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: another try at CLX "lots of result values"
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870423182233.4.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870424003902.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 23 Apr 87 18:22 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
I think the subset-returning functions you added to try to fix this actually
make the situation worse, because now there are two ways to access some data,
but only one way to access other data, things are less consistent, and the
programmer might have to spend a lot more time with his nose buried in a
manual.
I disagree. I don't see this as any worse than the fact that Genera, for example,
has :position and :edges as well as :x-offset and :y-offset and :height and :width
and :inside-size and ... You try and provide interfaces for common cases.
I don't think it's wise to take the current Genera window system as your
standard for quality of program interfaces. You should be able to do a
lot better.
As for the rest of the "lots of result values" discussion, I've said my
piece. If you're not listening, that's just an opportunity to poke fun
at the standard later when it's published, so I don't think we should
spend too much more time on this.
∂24-Apr-87 0741 decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM Mailing List
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87 07:39:57 PDT
Received: from decvax.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA28950; Fri, 24 Apr 87 06:40:56 PST
Received: from admin.uucp (mcae) by cvbnet.uucp (2.0/SMI-2.0)
id AA02965; Fri, 24 Apr 87 10:17:15 est
Received: by admin.uucp (1.1/SMI-3.0DEV3)
id AA13161; Fri, 24 Apr 87 10:13:14 EST
Date: Fri, 24 Apr 87 10:13:14 EST
From: decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM (Ted Bardasz)
Message-Id: <8704241513.AA13161@admin.uucp>
To: cvbnet!decvax!decwrl!SAIL.STANFORD.EDU!CL-WINDOWS@decwrl.DEC.COM
Subject: Mailing List
Hello,
Could you please add me to the mailing list for:
COMMON LISP WINDOWS
My mail address is:
decvax!cvbnet!basie!tbardasz@decwrl.dec.com
Thank you very much,
Ted Bardasz at Computervision Corp.
∂24-Apr-87 1024 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU CLX change summary
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Apr 87 10:24:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Apr 87 13:22-EDT
Date: Fri, 24 Apr 87 13:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX change summary
To: cl-windows@sail.stanford.edu
Message-ID: <870424132602.7.RWS@KILLINGTON.LCS.MIT.EDU>
The following is a summary of changes that have been made to the
original CLX proposal. The file /pub/clx.lisp, available via anonymous
ftp on milo.lcs.mit.edu, reflects all of these changes. The only
significant changes that haven't been mentioned before are:
1. various keyword arguments have changed to optional
(but some have remained keyword either for overall consistency
or for consistency with a paired function using the keyword form).
2. desire for local caching is now a property of a font object, and
the cache-p boolean has been removed from the querying functions.
In a subsequent message I will summarize what I think are the
outstanding issues.
new defstructs: window-attributes, drawable-geometry, pointer-info,
text-extents, keyboard-control
in display-error-handler, the display and error-key arguments to the
handler changed from positional to keyword, the array form of handler
changed to a sequence, and the error-key is passed even when the
handler is a sequence of functions
window-attributes function redefined
added functions: window-kind, window-gravity, window-backing-store,
window-colormap, window-map-state, window-event-masks
circulate-window split into circulate-window-up and circulate-window-down
drawable-geometry function redefined
added functions: drawable-depth, drawable-root
store-property renamed to change-property
added functions: intern-atom, find-atom, atom-name
both resource-ids and resource objects allowed as event components in
send-event, send-event-to-pointer-window, and send-event-to-input-focus
query-pointer function redefined
added functions: pointer-position, global-pointer-position
&optional (cache-p t) added to open-font, to determine whether QueryFont
results are retained locally
font-cache-p accessor and setf added
make-font creates with cache-p t
cache-p argument removed from text-extents and text-width
text-extents function redefined
added function: text-bounds
matching-fonts renamed to list-fonts
matching-fonts-and-properties renamed to list-fonts-with-info
accessors and setfs defined for gc components
added function: force-gc-changes
with-gc changed from process-locking semantics to per-process dynamic scope
start and end keywords added to draw-string, draw-string-image,
draw-string16, and draw-string-image16
keyboard-control function redefined
add-access-hosts changed to add-access-host (incorporates protocol change)
rem-access-hosts changed to remove-access-host (incorporates protocol change)
in next-event, the display and event-key arguments to the handler
changed from positional to keyword, the array form of handler changed
to a sequence, and the event-key is passed even when the handler is a
sequence of functions
in event-case, a t/otherwise clause is allowed
&key changed to &optional in following functions:
set-selection-owner, convert-selection, change-active-pointer-grab,
allow-events, set-input-focus, draw-points, draw-line, draw-rectangle,
draw-rectangles, draw-arc, draw-arcs, create-colormap, free-colors
∂24-Apr-87 1232 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU CLX issues
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Apr 87 12:32:16 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Apr 87 15:23-EDT
Date: Fri, 24 Apr 87 15:27 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX issues
To: cl-windows@sail.stanford.edu
Message-ID: <870424152743.4.RWS@KILLINGTON.LCS.MIT.EDU>
The following are the outstanding issues that I am aware of. I solicit
comments about all of them, and comments about any I have left out. At
the same time, I solicit "votes" to get an idea of how the proposal
stands (and how many people even care). The kind of vote I had in mind
is one of:
1. Good enough, if you fix the following nits
2. Good enough, if you make the following changes
3. Mostly good enough, but with the following problems (for which
I don't have a proposed solution)
4. Beyond hope
5. Don't have time to think about it
There are now individual setfs for gc components, in addition to
change-gc. It would be nice to eliminate change-gc. The only thing
standing in the way is being able to batch changes for uncached gcs. I
propose to solve this problem by redefining what caching means for gcs.
Instead of the cache being (member :off :write-through :write-back),
change it to just a boolean, with the following meaning. Regardless of
the cache mode, all changes are batched, and only written to the server
on a demand basis, or an explicit call to force-gc-changes. (I was
never truly convinced that a :write-through cache was all that useful,
so I don't see any real reason to retain it.) If the cache is off, then
no local copy of the gc state is retained, which means the accessors
always return nil, and setfs are never ignored. If the cache is on,
then local state is retained, and "redundant" setfs are ignored.
There is a question about whether gc's should be forced to retain dash
lists and clipping rectangle lists, in order to return them via the
corresponding accessors. My own bias is to allow these accessors to
return nil in this case.
It would appear that most CL implementations do not suffer from consing
lossage for keyword arguments, so I do not believe that is a compelling
reason to change next-event. However, I now tend to think that
event-case is the more desirable, and perhaps sufficient, interface.
So, I would be willing to consider dropping next-event completely. Are
there any good arguments for retaining a functional interface? The only
plausible one I can think of is to have a convenient way to cons up
structures, but a better solution to that might simply be to give in and
also define a set of structures and an explicit function for returning
them.
One minor aspect of event-case: the clauses currently contain a variable
list, from which the corresponding event value names are inferred.
Would it be worth allowing a (keyword var) specifier as for lambda-list
keywords, so that the variable name need not match the value name?
The only other issue about events is whether it should be possible to
specify a timeout value in event-case (and next-event). Presumably a
time value (in what units?) would replace hang-p, with zero equivalent
to no-hang, and nil equivalent to hang forever. Presumably a timeout
would simply cause event-case to return nil. An alternative would be to
just allow an optional timeout to event-listen.
Although I have been forced to argue on the "wrong" side of the debate
about accessors and setfs for window attributes, I do agree that it
would be great if there was a simple semantic (and implementation)
proposal that eliminated structures and multiple-values without causing
synchronization problems. The same holds true of geometry accessors,
and perhaps even geometry setfs as a replacement for configure-window.
I will continue to give it some thought, but a concrete proposal from
elsewhere ...
I would be willing to eliminate global-pointer-position, and redefine
pointer-position to return 8 values, and eliminate the pointer-info
defstruct (but retain pointer-position as a special case). I lean
toward liking this better than the structure interface.
I would be willing to eliminate text-bounds, and redefine text-extents
to return 8 values, and eliminate the text-extents defstruct (but retain
text-width as a special case). I lean toward liking this better than
the structure interface.
I would be willing to redefine keyboard-control to return 7 values, and
eliminate the keyboard-control defstruct. I lean toward liking this
better than the structure interface.
∂24-Apr-87 1701 moshell%ucf.csnet@RELAY.CS.NET
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 24 Apr 87 17:01:19 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab00811; 24 Apr 87 19:55 EDT
Received: from ucf.edu by RELAY.CS.NET id ab03052; 24 Apr 87 19:49 AST
Received: by localhost.UUCP (5.51/6.0.UCF)
id AA12377; Fri, 24 Apr 87 07:53:01 EDT
Date: Fri, 24 Apr 87 07:53:01 EDT
From: Mike Moshell <moshell%ucf.csnet@RELAY.CS.NET>
Posted-Date: Fri, 24 Apr 87 07:53:01 EDT
To: cl-windows@SAIL.STANFORD.EDU
Please remove me from the mailing list; my students are
now monitoring the mailings and will keep me informed. Thanks!
∂27-Apr-87 1814 Moon@STONY-BROOK.SCRC.Symbolics.COM CLX issues
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Apr 87 18:14:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 125684; Mon 27-Apr-87 21:13:45 EDT
Date: Mon, 27 Apr 87 21:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: CLX issues
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@sail.stanford.edu
In-Reply-To: <870424152743.4.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870427211337.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 24 Apr 87 15:27 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
The following are the outstanding issues that I am aware of.
No comment from me on most of the issues, but...
If the cache is off, then
no local copy of the gc state is retained, which means the accessors
always return nil
Returning the wrong value when it's too expensive to compute the right
value is a dangerous policy. Even if you think that no one in their
right mind would ever call the accessor in this case, some day someone
in their wrong mind will come along, get the NIL, and lose. I suggest
either making the accessors obtain the right value over the network, at
whatever cost, or else making the accessors signal an error.
Presumably a
time value (in what units?) would replace hang-p, with zero equivalent
to no-hang, and nil equivalent to hang forever.
Common Lisp generally uses seconds, with floating-point or ratio arguments
as the way to access units of time smaller than 1 second.
I solicit "votes"
I'm going to refrain from voting, because I don't think I know enough about
virtual consoles to be able to give an informed vote. Right now I'm mostly
participating from the Lisp side rather than the X Windows side. I haven't
seen any other replies to your message yet, but I sure hope I'm not the only
person on this mailing list!
∂27-Apr-87 2033 ACUFF@SUMEX-AIM.STANFORD.EDU CLX Issues; attribute interfaces
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Apr 87 20:33:18 PDT
Date: Mon, 27 Apr 87 20:33:40 PDT
From: Richard Acuff <Acuff@SUMEX-AIM.STANFORD.EDU>
Subject: CLX Issues; attribute interfaces
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12298000370.69.ACUFF@SUMEX-AIM.STANFORD.EDU>
I can't claim great familiarity with CLX, but I believe that I agree
strongly with Moon's proposed single function accessors. Is there any
reason that a wrapper macro couldn't be used to address batching and
synchronization issues?
-- Rich
-------
∂28-Apr-87 0858 Oren%Tilde%ti-csl.csnet@RELAY.CS.NET Re: CLX issues
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 28 Apr 87 08:57:47 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ag00490; 28 Apr 87 11:51 EDT
Received: from ti-csl by RELAY.CS.NET id al00118; 28 Apr 87 11:47 EDT
Received: from SI (si.ARPA) by tilde id AA26527; Tue, 28 Apr 87 10:44:08 cdt
Message-Id: <2755611781-3175100@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 28 Apr 87 09:43:01 MDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX issues
In-Reply-To: Msg of Fri, 24 Apr 87 15:27 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
I think the CLX proposal is good enough, with the following comments:
1. I agree with your proposal to eliminate :write-through mode on the GC
cache.
2. I think the GC cache should retain dash lists and clipping rectangle
lists.
3. I agree with David Moon that accessor macros should never return an
incorrect value, they should signal an error. It would be nice if an
accessor could get the value over the network, but there's no request
for doing this (is there?). Its not clear to me why someone would
turn the cache off - there's not that much overhead involved.
4. Get rid of NEXT-EVENT Standards shouldn't have more than one way to
perform the same operation. Its easy enough to get the functionality
of NEXT-EVENT using EVENT-CASE with an otherwise clause.
> One minor aspect of event-case: the clauses currently contain a variable
> list, from which the corresponding event value names are inferred.
> Would it be worth allowing a (keyword var) specifier as for lambda-list
> keywords, so that the variable name need not match the value name?
5. I thought CLX already did this. The documentation for EVENT-CASE says:
; Macro convenience for a call to next-event with a lexical closure.
I assumed this ment that the variable list for an event clause was
a CL lambda list. Since CL allows (keyword var), EVENT-CASE should
also.
6. EVENT-CASE needs a timeout option (in seconds). This is much better
than forcing applications developers to write non-portable code
to implement this critical feature.
7. The current solution for window-attributes drawable-geometry and
keyboard-control is "good enough", but I would prefer a wrapper
macro around accessor macros. The accessor macros can be made to
generate compile-time errors saying they're not inside the wrapper,
so there's no chance for error. I still don't understand why a
wrapper of this kind is "conceptually complex". It seems to me that
it would be better to standardize on a single powerful interface, and
let a toolkit provide structures and commonly used groupings of
multiple-valued returns.
8. Multiple-Values are probably better than structures for
query-pointer text-extents and keyboard-control. If someone really
wants structures, let them build it as part of a toolkit.
9. The (member :on :off) type on several of the parameters bothers me.
I understand that this was done to allow NIL to be the default value,
but it seems to me all this does is simplify the CLX implementation
at the expense of programmer confusion. It will be hard to remember
where to use T and NIL, and where to use :ON and :OFF.
∂28-Apr-87 1054 rfb@h.cs.cmu.edu CLX issues
Received: from H.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Apr 87 10:54:38 PDT
Date: 28 Apr 1987 13:47-EDT
From: Rick.Busdiecker@h.cs.cmu.edu
To: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
Cc: cl-windows@sail.stanford.edu
Subject: CLX issues
Message-Id: <546630449/rfb@h.cs.cmu.edu>
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
4. Get rid of NEXT-EVENT Standards shouldn't have more than one way to
perform the same operation. Its easy enough to get the functionality
of NEXT-EVENT using EVENT-CASE with an otherwise clause.
I disagree, and I think that the CommonLisp language standard sets
quite the opposite precedent. By the reasoning described above,
CommonLisp shouldn't have Case, If, Unless, and When because it's easy
enough to get the functionality of all of these using Cond.
Rick
∂29-Apr-87 1331 Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET Comments on CLX proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Apr 87 13:31:04 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa00794; 29 Apr 87 16:21 EDT
Received: from ti-csl by RELAY.CS.NET id aa08829; 29 Apr 87 16:15 EDT
Received: from dsg (juliett.ARPA) by tilde id AA01782; Wed, 29 Apr 87 14:29:20 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 29 Apr 87 14:32:07 CDT
Message-Id: <2755711707-2350331@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 29 Apr 87 14:28:27 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Comments on CLX proposal
The current CLX proposal is very good; its authors are to be commended for their
hard work. The comments below identify areas where I think some more work is
needed, as well as some areas where I feel more clarification is required. I
also added my comments on the current issues list. Items which represent major
concerns are marked by *.
Note: I found it somewhat difficult to keep track of the latest
document-plus-changes. I apologize in advance for any comments which are no
longer pertinent to the current document.
TECHNICAL COMMENTS
1. It's possible to improve the quality of the CLX language binding. In
general, a good language binding to a large function set can enhance
programmer productivity (by increasing the speed and reliability with
which the correct function call can be composed) and program
maintainability (by reducing the effort for a code reader to comprehend
a function call). Here are some specific changes which these principles
suggest.
o Productivity, Readability: Consistently use &key for all optional
arguments. The consistency promotes productivity, while the &key
syntax makes the meaning of the arguments clear. The overriding value
of maintainability should outweigh any objection to the "typeability"
of the &key syntax.
o Productivity: When possible, make the function name identical to the
corresponding request name. This reduces the total number of names
which the X programmer has to know and improves the transfer of X
knowledge from the C domain to the Lisp domain (and vice versa). I
note that recent document changes seem to have cured most of the
problems in this area.
o Productivity, Readability: Use function and argument names which
represent their corresponding meanings as exactly as possible. In case
of a conflict, this consideration should override the use of the X
request name. Some names which could be improved are:
display Replace with server
CONDITIONAL-WARP-POINTER Replace with WARP-POINTER-IF-INSIDE
KILL-TEMPORARY-CLIENTS Replace with KILL-TEMPORARY-RESOURCES
EVENT-LISTEN Replace with EVENTS-RECEIVED
NEXT-EVENT Replace with PROCESS-NEXT-EVENT
force-p Replace with force-output-p
o Productivity: When good language usage demands that a function name
differ from its X request counterpart, adopt a name "transformation
rule" and apply it consistently. The current binding represents a
reasonable attempt at this (for example, "GetFoo" always becomes
"FOO"), but it suffers from inconsistency. The biggest problem occurs
with "SetFoo" which sometimes becomes (SETF FOO) and other times
becomes SET-FOO. Another example is the handling of the "ListFoo"
requests. Even in the touchy case of "SetFoo", I think the binding
would be improved by picking one rule and sticking to it everywhere.
Actually, it seems to me that the X request names themselves have some
problems in this area. For example, why are some things "ChangeFoo"
and other things "SetFoo"?
* 2. A function to return an event to the head of the event queue is needed
(cp. XPutBackEvent in Xlib v10). This requirement comes from the need to
support a grammar-driven dialog controller. Is this what
QUEUE-EVENT-LOCALLY is supposed to do?
3. CREATE-WINDOW: parent, x, y, width, and height should probably be
required arguments (not &key). Alternatively, the defaults used for
these need to be specified.
* 4. SEND-EVENT, et al.: A single SEND-EVENT function is preferable because
this allows a useful parameterization of the operation. For example, it
would be nice if a function could accept just any old window as an
argument and SEND-EVENT to it, without having to decide how to dispatch
to one of SEND-EVENT, SEND-EVENT-TO-POINTER-WINDOW, or
SEND-EVENT-TO-INPUT-FOCUS. I realize this introduces the technical
problem of defining a window id value for (INPUT-FOCUS-OF display),
etc., but this can be dealt with (can't it?).
5. TRANSLATE-COORDINATES: My copy of the Xv11 spec indicates that the
values returned should be (values dst-x dst-y child same-screen-p).
6. For simplicity's sake, COPY-GC and COPY-GC-COMPONENTS should be combined
into a single function:
(defun copy-gc (src dst &rest keys)
(declare (type gc src dst)
(type (or null (list gc-key)) keys)))
7. STORE-COLORS: How about adding, as a convenience feature, the ability to
specify a color as a name here (as in STORE-COLOR)?
(type (repeat-seq (integer pixel) ((or stringable color) color)) specs)
8. I suggest using another package name, rather than "XLIB" (how about
"CLX"?). Otherwise, we risk adding unnecessarily to the confusion which
already confounds discussions of the many bits and pieces of X (e.g.
"Are you talking about the Lisp Xlib or the C Xlib?"). As with the
language binding, this is just a matter of finding a name that says what
is it is and doesn't say what it isn't.
9. Even though Xv11 allows a client to manipulate multiple displays, it's
reasonable to expect that a large majority of clients will use only one
display. However, several CLX functions require a display argument. This
suggests the following binding changes to improve CLX programmer
productivity.
o Add a function to establish the default display:
(defun set-default-display (display)
(declare (type display display)))
o For every function/macro with a display argument, move the display
argument from required to &key. Omitting the :display keyword argument
specifies the default display.
EDITORIAL COMMENTS
1. LIST-PROPERTIES: The value returned should be (sequence xatom).
2. NEXT-EVENT: Comments still refer to "flush-p".
QUESTIONS
1. WITH-POINTER-GRABBED, WITH-KEYBOARD-GRABBED: How does the macro caller
know if :success or :invalid-time was returned by the grab?
2. What are the other possible values of the :result-type argument? What
is the effect of this argument?
3. ADD-ACCESS-HOSTS, et al.: How is the protocol argument intended to be used?
4. EVENT-QUEUE-LENGTH: Is this the same as EVENT-LISTEN, except for the
value returned when the queue is empty? If so, it doesn't seem
necessary.
5. QUEUE-EVENT-LOCALLY: What exactly is the meaning of the append-p
argument?
6. NEXT-EVENT: What exactly is the meaning of the peek-p argument? What is
the default value of the handler argument?
ISSUES
1. Change gc :cache argument to boolean: Yes.
2. Result of accessor for uncached gc: Signal an error.
3. Retain dash lists and clip rectangles: Yes.
* 4. NEXT-EVENT vs. EVENT-CASE: Keep both. Some arguments in favor of
NEXT-EVENT's handler function(s) are:
o Some people will find it convenient and useful to modularize event
handler functions in this way. For example, it might be useful to
package up a "process a button press" function so it could be called
in several places; this could be a way to implement event "aliases".
EVENT-CASE doesn't prevent this kind of modularization, but it's clear
that NEXT-EVENT is a better fit, stylistically.
o Handler functions make it easier for a dialog controller to modify
event processing in response to user input (by "swapping in" new
handler functions).
o Handler functions make it easier to implement "out-of-band" events (i.e.
events that should be processed before and outside of the normal event
handling loop).
On the other hand, I think it is correct that many clients with
relatively simple input processing will find EVENT-CASE preferable.
I don't see a need to define event structures or functions that create them.
5. Allow (keyword var) specifier in EVENT-CASE clauses: Yes.
* 6. Specify timeout for NEXT-EVENT and EVENT-CASE: Yes! Replace (type
boolean hang-p) with (type (or null number) timeout), with the timeout
value given in seconds.
7. Handling of many return values for WINDOW-ATTRIBUTES: I support the
current solution. I think that, in the X world, the single-field accessor
model is the "wrong" side!
8. defstruct vs. multiple-values for POINTER-POSITION, TEXT-EXTENTS:
Multiple-values are OK in this case, because the information returned is
inherently short-lived and doesn't deserve cons'ing. Retaining
GLOBAL-POSITION-POINTER and TEXT-WIDTH as special cases is OK (perhaps
these could simply be a reordering of the same return values).
9. defstruct vs. multiple-values for KEYBOARD-CONTROL: The defstruct makes
more sense because of the longer expected lifetime of the information.
∂30-Apr-87 0835 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: "GC"
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 08:35:47 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 30 Apr 87 11:34-EDT
Date: Thu, 30 Apr 87 11:37 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: "GC"
To: Masinter.pa@Xerox.COM
cc: cl-windows@sail.stanford.edu
In-Reply-To: <870427-103123-4324@Xerox>
Message-ID: <870430113729.0.RWS@KILLINGTON.LCS.MIT.EDU>
Date: 27 Apr 87 10:29 PDT
From: Masinter.pa@Xerox.COM
I think that too many systems (and people) use "GC" as an abbreviation
for "Garbage Collection" for it to be a standard abbrvation for
"Graphics Context".
Is there a chance of changing this?
The abbreviation "GC" is too embedded in Xspeak, and "graphics context"
is too much for verbal communication, to eliminate GC from the
vernacular. However, it wouldn't bother me if "gc" were changed to
"gcontext" in function and type names. Is there any support for this?
Would anyone seriously object to the change?
∂30-Apr-87 1130 primerd!doug@enx.prime.pdn GC means Garbage Collection
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 11:30:21 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA23787@EDDIE.MIT.EDU>; Thu, 30 Apr 87 14:30:38 EDT
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA00860; Thu, 30 Apr 87 13:55:59 EDT
Message-Id: <8704301755.AA00860@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 30 Apr 87 13:30:40 EST
Subject: GC means Garbage Collection
To: cl-windows@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 30 Apr 87 13:30:40 EST
I agree that GC should be used for Garbage in the context of LISP.
Gcontext is a much less ambiguous term.
Doug
(doug@enx.prime.com)
∂30-Apr-87 1231 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU [Masinter.pa@Xerox.COM: Re: CLX issues]
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 12:31:05 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 30 Apr 87 15:25-EDT
Date: Thu, 30 Apr 87 15:28 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: [Masinter.pa@Xerox.COM: Re: CLX issues]
To: cl-windows@sail.stanford.edu
Message-ID: <870430152824.1.RWS@KILLINGTON.LCS.MIT.EDU>
Date: 27 Apr 87 12:05 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: CLX issues
My vote is somewhere between
3. Mostly good enough, but with the following problems (for which
I don't have a proposed solution)
4. Beyond hope
The problems have to do with the confusion between graphics contexts and
windows, the apparently random assortment of window types and
permutations assigned by parameters rather than, say, window class, a
large number of poorly chosen (i.e., not self-descriptive) names.
I think most of my problems are with X rather than CLX, however, i.e.,
perhaps you've done the best you could.
[A footnote from me (RWS): I agree to a certain extent with the
criticism of names being poorly chosen. When I first started fleshing
out the protocol design on paper, I tried to make it clear to "the
committee" that the names used in the drafts need not bear any
relationship to the names used in programming interfaces. However, as I
should have expected, we never put any serious effort into naming in the
protocol, and the Xlib designers for better or worse simply picked up
the names and used them, and now there is clear opinion from several
quarters that the Lisp names have to match the C names, to facilitate
language roamers.]
∂30-Apr-87 1422 harris%hplwhh@hplabs.HP.COM Re: GC means Garbage Collection
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 14:20:32 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Thu, 30 Apr 87 13:03:47 pdt
Received: from hplwhh (hplwhh) by hplms1; Thu, 30 Apr 87 13:03:22 pdt
Return-Path: <harris@hplwhh>
Received: from hplwhh.hpl.hp.com by hplwhh ; Thu, 30 Apr 87 13:03:05 pdt
Message-Id: <8704302003.AA00791@hplwhh>
To: cl-windows@sail.stanford.edu
Subject: Re: GC means Garbage Collection
In-Reply-To: Your message of 30 Apr 87 13:30:40 -0500.
<8704301755.AA00860@primerd.prime.com>
Date: Thu, 30 Apr 87 13:02:58 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
I too agree that GC is confusing in the context of lisp. Gcontext is
better, but how about GS for Graphics State, or GRAPHICS-CONTEXT (I
don't mind typing).
∂30-Apr-87 1606 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Comments on CLX proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 16:06:19 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 30 Apr 87 19:04-EDT
Date: Thu, 30 Apr 87 19:07 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Comments on CLX proposal
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2755711707-2350331@Sierra>
Message-ID: <870430190754.1.RWS@KILLINGTON.LCS.MIT.EDU>
[Thanks for the detailed response.]
Date: Wed, 29 Apr 87 14:28:27 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
o Productivity, Readability: Consistently use &key for all optional
arguments. The consistency promotes productivity, while the &key
syntax makes the meaning of the arguments clear. The overriding value
of maintainability should outweigh any objection to the "typeability"
of the &key syntax.
There is clearly mixed opinion on this issue, but there seems to be a slight
preference for having singletons be optional instead of keyword (hopefully
as embodied in the Draft Version 2).
o Productivity: When possible, make the function name identical to the
corresponding request name.
I will attempt another scan to identify differences, but if there are any in
particular you see, please point them out.
display Replace with server
Display is not only a recognized (e.g., by X3H3.6) term for this, but is also the
term used in the C interface (and one can imagine an implementation in which the
"server" isn't implemented as such), so I think this change would be inappropriate.
CONDITIONAL-WARP-POINTER Replace with WARP-POINTER-IF-INSIDE
KILL-TEMPORARY-CLIENTS Replace with KILL-TEMPORARY-RESOURCES
I have no objection to these. Anyone object?
EVENT-LISTEN Replace with EVENTS-RECEIVED
EVENT-LISTEN was chosen for its relationship to LISTEN on a stream, and as such
seems the more appropriate name.
NEXT-EVENT Replace with PROCESS-NEXT-EVENT
I would rather get rid of NEXT-EVENT altogether, but otherwise have no objection.
force-p Replace with force-output-p
Anyone object?
o Productivity: When good language usage demands that a function name
differ from its X request counterpart, adopt a name "transformation
rule" and apply it consistently. The current binding represents a
reasonable attempt at this (for example, "GetFoo" always becomes
"FOO"), but it suffers from inconsistency. The biggest problem occurs
with "SetFoo" which sometimes becomes (SETF FOO) and other times
becomes SET-FOO. Another example is the handling of the "ListFoo"
requests. Even in the touchy case of "SetFoo", I think the binding
would be improved by picking one rule and sticking to it everywhere.
Perhaps you could give me some concrete suggestions for name changes.
Actually, it seems to me that the X request names themselves have some
problems in this area. For example, why are some things "ChangeFoo"
and other things "SetFoo"?
Well, as I pointed out in previous mail, not that much thought went into naming
in the specification...
* 2. A function to return an event to the head of the event queue is needed
(cp. XPutBackEvent in Xlib v10). This requirement comes from the need to
support a grammar-driven dialog controller. Is this what
QUEUE-EVENT-LOCALLY is supposed to do?
Yes, that is what the function does.
3. CREATE-WINDOW: parent, x, y, width, and height should probably be
required arguments (not &key). Alternatively, the defaults used for
these need to be specified.
I disagree, making them keyword rather than positional, but still requiring them
to be non-nil and not supplying defaults seems perfectly reasonable to me, and
promotes both readability and ease of use.
* 4. SEND-EVENT, et al.: A single SEND-EVENT function is preferable because
this allows a useful parameterization of the operation. For example, it
would be nice if a function could accept just any old window as an
argument and SEND-EVENT to it, without having to decide how to dispatch
to one of SEND-EVENT, SEND-EVENT-TO-POINTER-WINDOW, or
SEND-EVENT-TO-INPUT-FOCUS. I realize this introduces the technical
problem of defining a window id value for (INPUT-FOCUS-OF display),
etc., but this can be dealt with (can't it?).
SEND-EVENT takes a window, not a window-id, and hence implies a display. If
this argument were allowed to be :input-focus or :pointer-window, then an
additional argument would be needed to specify the display. The original
draft was like this, with display as an additional optional keyword argument,
required only for :input-focus and :pointer-window. Is that better than
three separate functions?
5. TRANSLATE-COORDINATES: My copy of the Xv11 spec indicates that the
values returned should be (values dst-x dst-y child same-screen-p).
Hmm, missing type specifications, but good that you pointed it out. My
intention was to return nil when same-screen-p was false, rather than returning
zeroes and the boolean. Do you dislike that?
6. For simplicity's sake, COPY-GC and COPY-GC-COMPONENTS should be combined
into a single function:
(defun copy-gc (src dst &rest keys)
(declare (type gc src dst)
(type (or null (list gc-key)) keys)))
It was felt that having copy-gc copy everything when given no arguments was
counter-intuitive; by all rights it should copy nothing. Having it reduce
to everthing would almost certainly lead to obscure errors when dealing with
adding/removing things from a rest arg before passing it on to copy-gc.
7. STORE-COLORS: How about adding, as a convenience feature, the ability to
specify a color as a name here (as in STORE-COLOR)?
(type (repeat-seq (integer pixel) ((or stringable color) color)) specs)
I don't particularly object, but what synchronization semantics should it have?
That is, should the function first do lookup-color's and then perform a single
store-colors, or can it break the request up into separate store-colors and
store-color requests? Does it need to be defined?
8. I suggest using another package name, rather than "XLIB" (how about
"CLX"?). Otherwise, we risk adding unnecessarily to the confusion which
already confounds discussions of the many bits and pieces of X (e.g.
"Are you talking about the Lisp Xlib or the C Xlib?"). As with the
language binding, this is just a matter of finding a name that says what
is it is and doesn't say what it isn't.
I dislike "CLX", given that the "CL" part is both redundant and perhaps wrong (there
isn't that much CL about the interface that it couldn't mostly be used in other
dialects). Just "X" is too short. Any other suggestions? Any other objections
to "XLIB"?
9. Even though Xv11 allows a client to manipulate multiple displays, it's
reasonable to expect that a large majority of clients will use only one
display. However, several CLX functions require a display argument. This
suggests the following binding changes to improve CLX programmer
productivity.
o Add a function to establish the default display:
(defun set-default-display (display)
(declare (type display display)))
o For every function/macro with a display argument, move the display
argument from required to &key. Omitting the :display keyword argument
specifies the default display.
The point of making resources be compound objects instead of just raw X-ids
was to avoid explicit mention of the display in most operations. An explicit
display argument only shows up in infrequently used requests. Complicating
the interface for their benefit is counterproductive. I should also point
out that the C Xlib has switched over as well from the notion of a current
display to making it required in every call.
QUESTIONS
1. WITH-POINTER-GRABBED, WITH-KEYBOARD-GRABBED: How does the macro caller
know if :success or :invalid-time was returned by the grab?
It doesn't, except by setting some flag in the body. I think this is acceptable,
since in most cases either :invalid-time cannot occur, or not executing the body
is sufficient.
2. What are the other possible values of the :result-type argument? What
is the effect of this argument?
The result-type is used in the (effective) call to make-sequence, and is whatever
is acceptable to make-sequence.
3. ADD-ACCESS-HOSTS, et al.: How is the protocol argument intended to be used?
This was changed in Draft Version 2. Host objects alone are passed, and it is
unspecified how protocol and address are extracted.
4. EVENT-QUEUE-LENGTH: Is this the same as EVENT-LISTEN, except for the
value returned when the queue is empty? If so, it doesn't seem
necessary.
Correct, EVENT-LISTEN at one pointer returned a boolean rather than an integer.
EVENT-QUEUE-LENGTH should be flushed.
5. QUEUE-EVENT-LOCALLY: What exactly is the meaning of the append-p
argument?
T means to put the event at the tail of the queue, NIL means to put the
event at the head of the queue.
6. NEXT-EVENT: What exactly is the meaning of the peek-p argument? What is
the default value of the handler argument?
T for peek-p means the event (for which the handler returns non-nil) is not removed
from the queue (it is left in place), NIL means the event is removed.
∂01-May-87 0537 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: CLX issues
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 05:37:03 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 May 87 08:35-EDT
Date: Fri, 1 May 87 08:38 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: CLX issues
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2755611781-3175100@SI>
Message-ID: <870501083851.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 28 Apr 87 09:43:01 MDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
It would be nice if an [GC]
accessor could get the value over the network, but there's no request
for doing this (is there?).
No, there isn't.
Its not clear to me why someone would
turn the cache off - there's not that much overhead involved.
In order to have a gcontext shared by clients in different address spaces,
with loose coupling. Either there has to be a way to turn off the cache,
or else a way to back-door update the cache without causing the change to
propagate to the server. The former seems both simpler and preferable.
∂01-May-87 0628 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU attribute/geometry one more time
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 06:28:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 May 87 09:26-EDT
Date: Fri, 1 May 87 09:30 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: attribute/geometry one more time
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12298000370.69.ACUFF@SUMEX-AIM.STANFORD.EDU>
Message-ID: <870501093002.9.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Mon, 27 Apr 87 20:33:40 PDT
From: Richard Acuff <Acuff@SUMEX-AIM.STANFORD.EDU>
I can't claim great familiarity with CLX, but I believe that I agree
strongly with Moon's proposed single function accessors. Is there any
reason that a wrapper macro couldn't be used to address batching and
synchronization issues?
Date: Tue, 28 Apr 87 09:43:01 MDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
7. The current solution for window-attributes drawable-geometry and
keyboard-control is "good enough", but I would prefer a wrapper
macro around accessor macros. The accessor macros can be made to
generate compile-time errors saying they're not inside the wrapper,
so there's no chance for error.
I had also come around to the wrapper notion immediately after sending
out my issues&votes message, and have been discussing it with Moon.
Here is the idea; there are still details to work out. [If someone
proposed this a while back, I guess I just didn't understand it at
the time.]
There are individual accessors and setfs (as appropriate) for window
attributes and drawable geometries. There are no scope restrictions
on their use [I think this is very important], and in the normal case
there is no implied caching or batching of calls. In addition, there
needs to be some way to control caching/batching. There are four issues:
1. caching attributes for accessors
2. caching geometry for accessors
3. batching attribute changes from setfs
4. batching geometry changes from setfs
One could attempt to provide independent wrappers for these, but perhaps
a single wrapper is simpler and sufficient:
(with-cached-state (d) body)
where d is a drawable (window or pixmap). The meaning is roughly that
within the dynamic scope: all attributes for d are cached at the
execution of the first attribute accessor on d; all geometries for d are
cached at the execution of the first geometry accessor on d; the caches
are used for all subsequent accessors; all attribute and geometry setfs
on d are retained for a batched update on exit.
There are a several questions to be answered.
1. Should this caching/batching be per-process or global?
2. Is the result of a setf visible to a subsequent accessor? If so,
does the accessor cause all previous setfs to be forced out to
the server? If so, should another full geometry/attribute read
be performed before the accessor completes (since some setfs may
simply turn into advisory events at the server, rather than being
executed)?
3. If with-cached-state forms are nested, and specify the same d,
does the cache carry across, or is the cache invalidated and
reloaded on demand both on entry and exit from the nested form?
4. Are the issues related to batching of setfs sufficiently complex
that it would be simpler to retain change-window-attributes and
configure-window in addition to individual setfs, and have the
wrapper form only cause a read-cache for accessors (that wasn't
affected by setfs)?
If details can be worked out to satisfaction, this seems like a
better approach than the current structure/multipe-value mixture.
∂01-May-87 0747 DLW@ALDERAAN.SCRC.Symbolics.COM Comments on CLX proposal
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 1 May 87 07:46:58 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77145; Fri 1-May-87 10:22:48 EDT
Date: Fri, 1 May 87 10:23 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Comments on CLX proposal
To: RWS@ZERMATT.LCS.MIT.EDU, Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870430190754.1.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870501102330.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 30 Apr 87 19:07 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
8. I suggest using another package name, rather than "XLIB" (how about
"CLX"?). Otherwise, we risk adding unnecessarily to the confusion which
already confounds discussions of the many bits and pieces of X (e.g.
"Are you talking about the Lisp Xlib or the C Xlib?"). As with the
language binding, this is just a matter of finding a name that says what
is it is and doesn't say what it isn't.
I dislike "CLX", given that the "CL" part is both redundant and perhaps wrong (there
isn't that much CL about the interface that it couldn't mostly be used in other
dialects). Just "X" is too short. Any other suggestions? Any other objections
to "XLIB"?
I think "XLIB" is a good choice. It's true that there could be confusion
between the Lisp XLIB and the C XLib. But I think this is outweighed by the
benefits of making it clear that both of these things are instances of the
same level of abstraction and modularity. In other words, there really IS a
Lisp one and a C one, and the naming should reflect that reality in order to
make clear the relationship between the two.
∂01-May-87 1305 Moon@STONY-BROOK.SCRC.Symbolics.COM attribute/geometry one more time
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87 13:05:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 129679; Fri 1-May-87 16:05:08 EDT
Date: Fri, 1 May 87 16:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: attribute/geometry one more time
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870501093002.9.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870501160458.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 1 May 87 09:30 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
(with-cached-state (d) body)
There are several questions to be answered.
Here are my personal opinions.
If this thing is truly for synchronization, not just for caching,
I think the name should be changed. Perhaps with-copied-state
or with-local-copy would be better. Someone can probably think
of a better name than those.
1. Should this caching/batching be per-process or global?
with-xxx things are just about always per-process.
2. Is the result of a setf visible to a subsequent accessor? If so,
does the accessor cause all previous setfs to be forced out to
the server? If so, should another full geometry/attribute read
be performed before the accessor completes (since some setfs may
simply turn into advisory events at the server, rather than being
executed)?
This is a toughy. The criterion should be that accessors and setfs
behave consistently, regardless of whether they are inside a
with-cached-state. So here's what I think:
The caching/batching is for sequences of only reads or only writes. Any
transition between reading and writing is like exiting the wrapper form
and entering it again. Thus the first read in a sequence forces batched
changes then fetches the state from the server and caches it. The first
write in a sequence invalidates this cache and starts batching changes.
Exiting a with-cached-state forces batched changes.
Thus the answers to your questions would be yes, yes, and yes.
3. If with-cached-state forms are nested, and specify the same d,
does the cache carry across, or is the cache invalidated and
reloaded on demand both on entry and exit from the nested form?
For reads, it is invisible whether the cache is carried across or
invalidated and reloaded. I don't think it matters which you do. For
writes, the batched changes should be sent to the server when any
with-cached-state is exited, even nested ones.
4. Are the issues related to batching of setfs sufficiently complex
that it would be simpler to retain change-window-attributes and
configure-window in addition to individual setfs, and have the
wrapper form only cause a read-cache for accessors (that wasn't
affected by setfs)?
I don't think the issues are so complex if you think of
(with-cached-state (d)
(setf (drawable-x d) a)
(setf (drawable-y d) b))
and
(configure-window d :x a :y b)
as two equivalent syntaxes for the same thing. (I'm sure I have made
programming errors here, ignore them). The complex issues are more for
implementors than for callers, so I wouldn't say they are much of a
problem.
∂01-May-87 1705 Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET Re: Comments on CLX proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 1 May 87 17:05:25 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac07948; 1 May 87 19:45 EDT
Received: from ti-csl by RELAY.CS.NET id ao23636; 1 May 87 19:38 EDT
Received: from dsg (juliett.ARPA) by tilde id AA04567; Fri, 1 May 87 17:25:51 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 1 May 87 15:14:08 CDT
Message-Id: <2755886529-12853913@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Fri, 1 May 87 15:02:09 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: Comments on CLX proposal
In-Reply-To: Msg of Thu, 30 Apr 87 19:07 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
> o Productivity: When good language usage demands that a function name
> differ from its X request counterpart, adopt a name "transformation
> rule" and apply it consistently. The current binding represents a
> reasonable attempt at this (for example, "GetFoo" always becomes
> "FOO"), but it suffers from inconsistency. The biggest problem occurs
> with "SetFoo" which sometimes becomes (SETF FOO) and other times
> becomes SET-FOO. Another example is the handling of the "ListFoo"
> requests. Even in the touchy case of "SetFoo", I think the binding
> would be improved by picking one rule and sticking to it everywhere.
>
>Perhaps you could give me some concrete suggestions for name changes.
I suggest the following transformation rules.
1. ChangeFoo and SetFoo --> change-foo. An alternative would be to adopt
consistently the defsetf form. However, I think the setf/accessor model is
wrong for client operations on a (remote) server database. The specific
changes would be:
ChangeAccessControl: change-access-control (replaces defsetf)
ChangeCloseDownMode: change-close-down-mode (replaces defsetf)
SetFontPath : change-font-path (replaces defsetf)
SetInputFocus : change-input-focus (replaces set-input-focus)
SetKeyboardMapping : change-keyboard-mapping (replaces defsetf)
SetPointerMapping : change-pointer-mapping (replaces defsetf)
SetScreenSaver : change-screen-saver (replaces set-screen-saver)
SetSelectionOwner : change-selection-owner (replaces set-selection-owner)
2. ListFoo --> foo. An alternative would be list-foo, but the term "list" is
too suggestive (?!) in a Lisp binding; in fact, each of these functions is
capable of returning a list or not, depending on the :result-type
argument. The specific changes would be:
ListExtensions : extensions (replaces list-extensions)
ListFontsWithInfo : fonts-with-info (replaces list-fonts-with-info)
ListFonts : fonts (replaces list-fonts)
ListProperties : properties (replaces list-properties)
hat could use improvement is QUEUE-EVENT-LOCALLY, since "locally"
is superfluous and the name doesn't suggest "add an event at either end of the
queue". But this isn't easy to do! Some possibilities are: put-event-queue,
enqueue-event, queue-event.
> * 4. SEND-EVENT, et al.: A single SEND-EVENT function is
> preferable because this allows a useful parameterization of
> the operation. For example, it would be nice if a function
> could accept just any old window as an argument and
> SEND-EVENT to it, without having to decide how to dispatch
> to one of SEND-EVENT, SEND-EVENT-TO-POINTER-WINDOW, or
> SEND-EVENT-TO-INPUT-FOCUS. I realize this introduces the
> technical problem of defining a window id value for
> (INPUT-FOCUS-OF display), etc., but this can be dealt with
> (can't it?).
>
>SEND-EVENT takes a window, not a window-id, and hence implies a display. If
>this argument were allowed to be :input-focus or :pointer-window, then an
>additional argument would be needed to specify the display. The original
>draft was like this, with display as an additional optional keyword argument,
>required only for :input-focus and :pointer-window. Is that better than
>three separate functions?
Not really, since this still doesn't support the parameterization described
above. How about, instead, changing the type of window-id to be (or integer
:input-focus :pointer-window)? This would allow a window object representing
"the input focus of display A" to be built and used just like any other. The
send-event function would be responsible for detecting this kind of window and
building the appropriate request.
>5. TRANSLATE-COORDINATES: My copy of the Xv11 spec indicates that the
> values returned should be (values dst-x dst-y child
> same-screen-p).
>
>Hmm, missing type specifications, but good that you pointed it out. My
>intention was to return nil when same-screen-p was false, rather than
>returning zeroes and the boolean. Do you dislike that?
No, sounds OK to me.
>7. STORE-COLORS: How about adding, as a convenience feature, the ability to
> specify a color as a name here (as in STORE-COLOR)?
>
>I don't particularly object, but what synchronization semantics should it have?
>That is, should the function first do lookup-color's and then perform a single
>store-colors, or can it break the request up into separate store-colors and
>store-color requests? Does it need to be defined?
I presume that RGB names will be things like "red" and "burnt-siena" and not
things like "background-color" (the latter sort ought to be identified by pixel
values, not RGB's). Thus, since the RGB associated with a name can be expected
to change very slowly or not at all, synchronization should not be a critical
issue. I think either of the implementation techniques you describe could be
used, and that the semantics of store-colors need not be defined to preclude
either one.
>8. I suggest using another package name, rather than "XLIB" (how about
> "CLX"?). Otherwise, we risk adding unnecessarily to the confusion
> which already confounds discussions of the many bits and pieces of
> X (e.g. "Are you talking about the Lisp Xlib or the C Xlib?"). As
> with the language binding, this is just a matter of finding a name
> that says what is it is and doesn't say what it isn't.
>
>I dislike "CLX", given that the "CL" part is both redundant and perhaps wrong (there
>isn't that much CL about the interface that it couldn't mostly be used in other
>dialects). Just "X" is too short. Any other suggestions?
How about XLISP? LIX (Lisp Interface to X)? CLIX (C*mm*n Lisp Interface to X)?
>9. Even though Xv11 allows a client to manipulate multiple displays, it's
> reasonable to expect that a large majority of clients will use only one
> display. However, several CLX functions require a display argument. This
> suggests the following binding changes to improve CLX programmer
> productivity.
>
> o Add a function to establish the default display:
> (defun set-default-display (display)
> (declare (type display display)))
>
> o For every function/macro with a display argument, move the display
> argument from required to &key. Omitting the :display keyword argument
> specifies the default display.
>
>The point of making resources be compound objects instead of just raw X-ids
>was to avoid explicit mention of the display in most operations. An explicit
>display argument only shows up in infrequently used requests. Complicating
>the interface for their benefit is counterproductive. I should also point
>out that the C Xlib has switched over as well from the notion of a current
>display to making it required in every call.
To me, the optional :display argument looks like a net simplification. It is
certainly simpler for one-display clients (the 80% case), while for n-display
clients, (foo :display A) is not appreciably more complex than (foo A). The
chief argument in favor of this approach has nothing to do with "typeability".
Rather, the idea is to increase programmer productivity by relieving him from
having to know which functions require a display argument and which don't in the
case where he shouldn't have to repeatedly identify the display anyway. I
imagine Xlib wanted to avoid a modal specification of "the current display",
since this can cause difficulties for a n-display client. However, unlike Xlib,
we can get away with this without having to go strictly modal; implicit
references to the default display could be freely intermixed with explicit
display references.
>1. WITH-POINTER-GRABBED, WITH-KEYBOARD-GRABBED: How does the macro caller
> know if :success or :invalid-time was returned by the grab?
>
>It doesn't, except by setting some flag in the body. I think this is acceptable,
>since in most cases either :invalid-time cannot occur, or not executing the body
>is sufficient.
But if the caller expects that :invalid-time cannot occur and it *DOES* occur,
then this is bug which should not go undetected. Also, the body can have
arbitrary side-effects:
(with-pointer-grabbed
(delete-file "foo"))
(create-file "foo")
so it can be important to know whether the body was executed or not. I would
prefer to see these macros return a simple boolean or :success/:invalid-time.
∂01-May-87 2109 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Comments on CLX proposal
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87 21:09:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130105; Sat 2-May-87 00:09:40 EDT
Date: Sat, 2 May 87 00:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Comments on CLX proposal
To: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2755886529-12853913@Sierra>
Message-ID: <870502000912.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Frankly, most of your proposed improvements sound to me like
disimprovements that would make the interface more confusing for
programmers and harder to use. I suppose what this shows is that it is
all a matter of taste, but I wonder how other members of the cl-windows
mailing list feel.
∂02-May-87 0808 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU NIL in CLX
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 08:08:27 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 2 May 87 11:06-EDT
Date: Sat, 2 May 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: NIL in CLX
To: cl-windows@sail.stanford.edu
Message-ID: <870502111031.8.RWS@KILLINGTON.LCS.MIT.EDU>
A few people have said they would prefer the gcontext accessors to
signal an error rather than return the "wrong" value. After I thought
about this, I finally realized what was meant. The original plan I had
for gcontext components was that NIL was never a legal value. This is
true of everything but (I see now) the clip-mask, for which an empty
sequence is legal (if unusual, since it effectively disables all
graphics output, which is different from :none, which is a full-drawable
clip). [An empty dashes sequence is not legal.] My intent was that
accessors would return NIL to indicate "unknown", rather than
signalling, because checking for NIL seems more convenient than handling
signals.
Note that even if a gcontext has caching enabled, it won't always be
possible for the accessors to return a correct value. This is true of
the default tile, stipple, and font values (I suppose :default could be
returned, but I don't really think setf should accept :default), but
also any copying from an uncached to a cached gc will "infect"
components of the cached gc with unknown values.
Related to this is the fact that I have defined create-window,
create-gc, and with-gc (and others) so that passing a keyword argument
as NIL is the same as not passing it. That is, NIL means "ignore me".
I thought this was important for create-window and create-gc, because I
have been burned by wanting to provide a function at a higher level that
accepts some or all of the same keyword arguments, and then pass them
down; either you have to propagate knowledge of default values, or you
have to use a rest argument or some other hackery. Making a few values
:on, :off, and :none seemed worth it to preserve NIL as an ignore value.
I would like to hear comments on all of this. Is it useful to retain
NIL as "ignore" and "unknown"? The void clip-mask is the only conflict
that I can see. If these uses of NIL are removed, then all instances of
:none could be changed to NIL except in clip-mask, and all instances of
(member :on :off) could be changed to boolean, and presumably gcontext
accessors would be defined to signal for unknown components.
∂04-May-87 1218 Oren%Tilde%ti-csl.csnet@RELAY.CS.NET Re: NIL in CLX
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 May 87 12:18:14 PDT
Received: from relay2.cs.net by RELAY.CS.NET id af26489; 4 May 87 12:52 EDT
Received: from ti-csl by RELAY.CS.NET id ac08987; 4 May 87 12:47 EDT
Received: from SI (si.ARPA) by tilde id AA11314; Mon, 4 May 87 11:07:28 cdt
Message-Id: <2756131580-3224533@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 4 May 87 11:06:20 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: NIL in CLX
In-Reply-To: Msg of Sat, 2 May 87 11:10 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
> I have been burned by wanting to provide a function at a higher level that
> accepts some or all of the same keyword arguments, and then pass them
> down; either you have to propagate knowledge of default values, or you
> have to use a rest argument or some other hackery. Making a few values
> :on, :off, and :none seemed worth it to preserve NIL as an ignore value.
I agree that there needs to be some way of passing a value that says
"use the default".
> I would like to hear comments on all of this. Is it useful to retain
> NIL as "ignore" and "unknown"?
Yes.
I'm used to thinking of NIL as false or the empty-list. However, if CLX
consistently uses nil for "ignore" and "unknown", its OK with me. Doing
this is probably better than using a :DEFAULT keyword everywhere.
LaMott
∂04-May-87 1819 Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET Re: NIL in CLX
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 May 87 18:19:04 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa01432; 4 May 87 21:02 EDT
Received: from ti-csl by RELAY.CS.NET id aw11524; 4 May 87 20:54 EDT
Received: from dsg (juliett.ARPA) by tilde id AA19317; Mon, 4 May 87 15:53:07 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 4 May 87 11:08:33 CDT
Message-Id: <2756138629-529754@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 4 May 87 13:03:49 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: NIL in CLX
Your idea of using NIL as the "ignore" or "use the default" value for
keyword arguments is a good one. Also, your observation about the
potential for "infection" of cached gcontexts has persuaded me that it's
proper for accessors to return NIL rather than signal an error.
∂04-May-87 1820 Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET Re: attribute/geometry one more time
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 May 87 18:20:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ad01432; 4 May 87 21:02 EDT
Received: from ti-csl by RELAY.CS.NET id ba11524; 4 May 87 20:55 EDT
Received: from dsg (juliett.ARPA) by tilde id AA19710; Mon, 4 May 87 16:01:26 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 4 May 87 13:54:14 CDT
Message-Id: <2756141652-711382@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 4 May 87 13:54:12 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: attribute/geometry one more time
Well, every time it comes around, it gets better! The latest notion
(i.e. setf/accessors, no implied caching or batching, with-xxx wrapper
macro), *plus* the issue resolutions suggested by Moon (i.e.
write-/read-only caching/batching, per process) sounds good to me. I
can support this proposal because it satisfies one of my main concerns:
that the interface should not try to distort the Xreality of separate
client/server address spaces and network requests.
In fact, assuming the semantics proposed by Moon, there is a very close
correspondence (I think it will typically be one-to-one) between a
with-xxx wrapper call and an X request. This suggests that a good name
for the wrapper might be something like "with-single-request". Perhaps a
more accurate name would be "with-minimum-requests".
∂05-May-87 1223 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: Comments on CLX proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 May 87 12:22:56 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 May 87 15:20-EDT
Date: Tue, 5 May 87 15:22 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: Comments on CLX proposal
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2755886529-12853913@Sierra>
Message-ID: <870505152206.0.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Fri, 1 May 87 15:02:09 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
I think the setf/accessor model is
wrong for client operations on a (remote) server database. The specific
changes would be:
ChangeAccessControl: change-access-control (replaces defsetf)
ChangeCloseDownMode: change-close-down-mode (replaces defsetf)
SetFontPath : change-font-path (replaces defsetf)
SetKeyboardMapping : change-keyboard-mapping (replaces defsetf)
SetPointerMapping : change-pointer-mapping (replaces defsetf)
The general opinion seems to be that the accessor/setf model is preferable overall,
so I would rather not change these.
SetInputFocus : change-input-focus (replaces set-input-focus)
SetScreenSaver : change-screen-saver (replaces set-screen-saver)
The only reason these aren't setfs is that CL doesn't support multiple values.
The bug is with CL, and I would rather leave the names "set-". The "change-"
names are intended to convey that it is not a wholesale replacement of contents.
SetSelectionOwner : change-selection-owner (replaces set-selection-owner)
This one can in fact be recast as a setf:
(defun set-selection-owner (display selection owner &optional time))
=>
(defsetf selection-owner (display selection &optional time) (owner))
and I guess I would prefer that, if there are no objections.
ListExtensions : extensions (replaces list-extensions)
ListFontsWithInfo : fonts-with-info (replaces list-fonts-with-info)
ListFonts : fonts (replaces list-fonts)
ListProperties : properties (replaces list-properties)
I don't know what to do here. Some argue the names should match the protocol,
others argue the names should match the C Xlib, others argue the names should
make sense. I don't care, as long as everyone is happy, which is unlikely.
For comparison, the C Xlib names are XListExtensions, XFontNamesWithInfo,
XFontNames, and XListProperties.
hat could use improvement is QUEUE-EVENT-LOCALLY, since "locally"
is superfluous and the name doesn't suggest "add an event at either end of the
queue". But this isn't easy to do! Some possibilities are: put-event-queue,
enqueue-event, queue-event.
Happy to drop the -LOCALLY.
SEND-EVENT ...
How about, instead, changing the type of window-id to be (or integer
:input-focus :pointer-window)? This would allow a window object representing
"the input focus of display A" to be built and used just like any other. The
send-event function would be responsible for detecting this kind of window and
building the appropriate request.
:input-focus and :pointer-window aren't reasonable anywhere outside of SEND-EVENT.
It would be unacceptable to have to check for this elsewhere. It seems to me
the only possible changes are to 1) allow a keyword as the window and require
an additional display argument in that case or 2) allow some funny object (like
a list containing a keyword and a display) in the window position. I guess I
like 1) better than 2), but I have no strong feelings about 1) versus the current
three functions.
STORE-COLORS ...
Thus, since the RGB associated with a name can be expected
to change very slowly or not at all, synchronization should not be a critical
issue.
The synchronization is not with the RGB for "aqua" changing, but with whether the
colormap got changed in one or multiple steps (which can cause visual glitches).
I think either of the implementation techniques you describe could be
used, and that the semantics of store-colors need not be defined to preclude
either one.
I guess that is fine with me, since it is an extension of the fundamental interface.
How about XLISP? LIX (Lisp Interface to X)? CLIX (C*mm*n Lisp Interface to X)?
I think XLIB is just fine.
To me, the optional :display argument looks like a net simplification. It is
certainly simpler for one-display clients (the 80% case), while for n-display
clients, (foo :display A) is not appreciably more complex than (foo A). The
chief argument in favor of this approach has nothing to do with "typeability".
Rather, the idea is to increase programmer productivity by relieving him from
having to know which functions require a display argument and which don't in the
case where he shouldn't have to repeatedly identify the display anyway.
I will rephrase my previous statement, that the functions making up perhaps 90% of
all syntactic calls don't take a display argument anyway; complicating the interface
for the other functions just doesn't seem worth it. If you argued about defaulting
the window or gcontext argument, that would then cover more interesting territory,
but again I would argue against it.
WITH-<DEVICE>-GRABBED ...
But if the caller expects that :invalid-time cannot occur and it *DOES* occur,
then this is bug which should not go undetected. Also, the body can have
arbitrary side-effects:
(with-pointer-grabbed
(delete-file "foo"))
(create-file "foo")
so it can be important to know whether the body was executed or not. I would
prefer to see these macros return a simple boolean or :success/:invalid-time.
Not returning what the body returns seems like a very bad idea. If there isn't
sufficient consensus, these two macros could just be eliminated, since they are
merely unwind-protect convenience (plus periodic but unspecified retry, which
might be either a reason to keep or eliminate them, depending on your point of
view).
∂05-May-87 1255 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: NIL in CLX
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 May 87 12:55:18 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 May 87 15:52-EDT
Date: Tue, 5 May 87 15:54 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: NIL in CLX
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2756138629-529754@Sierra>
Message-ID: <870505155411.5.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Mon, 4 May 87 13:03:49 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
Your idea of using NIL as the "ignore" or "use the default" value for
keyword arguments is a good one. Also, your observation about the
potential for "infection" of cached gcontexts has persuaded me that it's
proper for accessors to return NIL rather than signal an error.
There is still the problem of what to do with the empty sequence as a
valid clip-mask, which as a list is NIL, which isn't "ignore" or
"default". Do we just special case this one thing with an svar in
CREATE-GC and WITH-GC?
∂06-May-87 0911 Oren%Tilde%ti-csl.csnet@RELAY.CS.NET Re: NIL in CLX
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 May 87 09:10:57 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac13750; 6 May 87 12:01 EDT
Received: from ti-csl by RELAY.CS.NET id an22650; 6 May 87 11:54 EDT
Received: from SI (si.ARPA) by tilde id AA10121; Wed, 6 May 87 09:09:37 cdt
Message-Id: <2756297339-9696988@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 6 May 87 09:08:59 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: NIL in CLX
In-Reply-To: Msg of Tue, 5 May 87 15:32 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
> Date: Tue, 5 May 87 15:32 EDT
> From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
>
> This hasn't answered the question of what to do about NIL as a valid clip-mask.
A NIL clip-mask doesn't seem very interesting or useful, so I would not
make it easy to get. I would do:
(declare (type (or null (member :none :disable-graphics) pixmap rect-seq) clip-mask)
If someone REALLY wants to use a null clipping rectangle list, let them do:
(change-gc gc :clip-mask (or clipping-rectangles :disable-graphics))
I think this is better than violating the "Nil is ignore" convention.
Using a "svar" for clip-mask would make it too easy to accidently set a
null clipping rectangle list.
-LaMott
P.S. Perhaps you can think of a better keyword than :disable-graphics
∂06-May-87 0916 Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET send-event: one function or three?
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 May 87 09:16:32 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac13790; 6 May 87 12:06 EDT
Received: from ti-csl by RELAY.CS.NET id ay22650; 6 May 87 12:01 EDT
Received: from dsg (juliett.ARPA) by tilde id AA13011; Wed, 6 May 87 10:38:35 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 6 May 87 10:38:41 CDT
Message-Id: <2756302713-4357676@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 6 May 87 10:38:33 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: send-event: one function or three?
I've thought about this some more and no longer have any objections to
the following one-function interface.
(defun send-event (window event-key event-mask &rest args
&key display propagate-p &allow-other-keys)
(declare (type window (or window :input-focus :pointer-window))
(type event-key event-key)
(type event-mask event-mask)
(type display (or null display))
(type boolean propagate-p)))
I can see the rationale for the three-function interface, in terms
of tidying up the argument lists. But, I feel that the one-function
interface has the important advantage of uniformity -- a function can
send events to any destination without special casing or extra
dispatching logic.
∂06-May-87 1205 unido!gmdzi!LISPM-2.GMD!@lispm-1.gmd.hws Info about CLX and X
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 6 May 87 12:05:37 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA13570; Wed, 6 May 87 15:04:16 EDT
Received: by unido.uucp with uucp;
Wed, 6 May 87 15:50:49 +0100
Received: by gmdzi.UUCP id AA03055; Wed, 6 May 87 10:46:02 -0100
Received: from LISPM-2.GMD by LISPM-1.GMD via CHAOS with CHAOS-MAIL id 1454; Wed 6-May-87 10:44:08-CET
Date: Wed, 6 May 87 10:44 CET
From: "Heinz W. Schmidt" <unido!gmdzi!LISPM-2!hws@seismo.CSS.GOV>
Subject: Info about CLX and X
To: gmdzi!LISPM-1!cl-windows@seismo.CSS.GOV
Cc: gmdzi!LISPM-2!hws@seismo.CSS.GOV
In-Reply-To: <870415113622.1.RWS@KILLINGTON.LCS.MIT.EDU>
Message-Id: <870506104407.5.HWS@LISPM-2.GMD>
Please tell me how I can get info about CLX.
I've followed the postings in this group for some days but need
more complete info to follow up. In particular:
Is there a specification/documentation available for CLX?
Does CLX interface to X10 or X11?
How is CLX related to SUN NeWS? (And what is the state of NeWS development?).
We have SUN3s (LUCID CL 2 is available but X not yet) and SYMBOLICS' (Rel 7) and
work with an own simple interface to windows/menus/mouse (written in CL and
FLAVORS) for improving portability of our CL code.
The SUN CL is available only since a few days now and we are starting to implement
this interface on SUN's. Does anybody out there have experience with
developing LISP programs on SYMBOLICS (and maybe SUN) which use windows and should
be *portable* to SUNs?
∂06-May-87 1329 dcmartin@postgres Re: Info about CLX and X
Received: from [128.32.149.1] by SAIL.STANFORD.EDU with TCP; 6 May 87 13:29:21 PDT
Received: by postgres (3.2/1.22)
id AA02816; Wed, 6 May 87 13:27:58 PDT
Message-Id: <8705062027.AA02816@postgres>
From: David C. Martin <dcmartin@postgres>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: "Heinz W. Schmidt" <unido!gmdzi!LISPM-2!hws@seismo.css.gov>
Cc: cl-windows@sail.stanford.edu
Precedence: special-delivery
In-Reply-To: Your message of Wed, 6 May 87 10:44 CET
<870506104407.5.HWS@LISPM-2.GMD>
Subject: Re: Info about CLX and X
Date: Wed, 06 May 87 13:27:56 PDT
Sender: dcmartin@postgres
I don't think this will reach you Heinz, so I am sending it to the whole list.
I have a package called XCL which provides the X version 10 C language
X library functions w/ some extensions in Common LISP. It currently runs
on ExCL from Franz, Inc and Kyoto Common LISP - I have not yet gotten a Lucid
port done, but it shouldn't be too hard (I have the documentation to do it,
just haven't gotten around to it).
The code contains support for everything in the C language library w/ the
exception of color and resource id -> user data structures. It is available
by public ftp from ingres.Berkeley.EDU in ~ftp/bool/xcl (including
documentation and demos). If you can't get to the Internet, then a tape can
be sent (although we haven't yet done it, it can be done.. I think it would
cost about $100).
Hope this helps.
dcm
∂08-May-87 0611 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU change-pointer-control rational argument
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 May 87 06:11:45 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 May 87 08:36-EDT
Date: Fri, 8 May 87 08:38 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: change-pointer-control rational argument
To: cl-windows@sail.stanford.edu
Message-ID: <870508083829.1.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 7 May 87 12:08:50 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
change-pointer-control declares the acceleration parameter to be:
(type (or null (member :default) rational)
I think it would be better to make this
(type (or null (member :default) number)
and have change-pointer-control rationalize it if a float is passed in.
Seems rational to me.
∂08-May-87 1258 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU setf'ing device mappings
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 May 87 12:58:34 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 May 87 15:55-EDT
Date: Fri, 8 May 87 15:57 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: setf'ing device mappings
To: cl-windows@sail.stanford.edu
In-Reply-To: <2756388727-15187199@SI>
Message-ID: <870508155730.3.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 7 May 87 10:32:07 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
CLX defines the following:
(defsetf keyboard-mapping (display) (map)
(declare (type display display)
(type (sequence integer) map)))
(defsetf pointer-mapping (display) (map)
(declare (type display display)
(type (sequence integer) map)))
Its traditional for SETF to return the value that's passed in. However,
the X requests SetKeyboardMapping and SetPointerMapping both return a
status (member :success :busy). Do you expect CLX to wait and retry,
and/or signal an error when :busy status is returned, or does SETF
return the status?
I intended that the setf signal a device-busy error.
∂08-May-87 1307 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: NIL in CLX
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 May 87 13:06:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 May 87 16:00-EDT
Date: Fri, 8 May 87 16:01 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: NIL in CLX
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2756297339-9696988@SI>
Message-ID: <870508160155.4.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 6 May 87 09:08:59 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
If someone REALLY wants to use a null clipping rectangle list, let them do:
(change-gc gc :clip-mask (or clipping-rectangles :disable-graphics))
P.S. Perhaps you can think of a better keyword than :disable-graphics
Yes, I would prefer to not introduce the keyword at all and let them do:
(change-gc gc :clip-mask (or clipping-rectangles (make-array 0)))
[Of course change-gc is going away, but this is true of create-gcontext and
with-gcontext.]
∂08-May-87 1327 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU timeout in event-case
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 May 87 13:27:44 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 May 87 16:25-EDT
Date: Fri, 8 May 87 16:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: timeout in event-case
To: cl-windows@sail.stanford.edu
Message-ID: <870508162657.8.RWS@KILLINGTON.LCS.MIT.EDU>
I was changing hang-p to timeout in process-event (aka next-event) and
event-case (specified as a number in seconds), and realized that there
is a semantic question. Should the waiting only apply if the queue is
initially empty and only until the queue goes non-empty, or should it
apply until some non-nil value is returned? (Or be an option, yech.)
The former is easier to do in bsd Unix (pass the argument to the select
system call). The latter seems correct, but is more expensive, since
(last I knew) select didn't return the time remaining on success. This
means doing gettimeofday system calls, which substantially increases the
overhead. Comments?
By the way, most issues now seem pretty much resolved. I've been
side-tracked with other things, but I hope to send out a new draft and
diffs before the 15th.
∂09-May-87 0538 RAM@C.CS.CMU.EDU timeout in event-case
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 May 87 05:37:54 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 9 May 87 08:37:13-EDT
Date: Sat, 9 May 1987 08:37 EDT
Message-ID: <RAM.12300982889.BABYL@>
From: Rob MacLachlan <RAM@λλ>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: timeout in event-case
In-reply-to: Msg of 8 May 1987 16:26-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
I have no objection to having a wait with timeout return before the
full time has elapsed. Timeouts are generally of an advisory nature
anyway. If the user wants to wait a specific amount of time, he can
always keep track of the elapsed time by using get-internal-real-time.
Rob
∂11-May-87 1651 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU CLX draft 3 revisions
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 16:51:38 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 11 May 87 19:33-EDT
Date: Mon, 11 May 87 19:35 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX draft 3 revisions
To: cl-windows@sail.stanford.edu
Message-ID: <870511193549.4.RWS@KILLINGTON.LCS.MIT.EDU>
A separate message will contain Draft Version 3 of the CLX proposal.
It is also available via anonymous ftp to milo.lcs.mit.edu.
Below is a (hopefully complete) summary of revisions from Version 2.
A few things (like with-state) no doubt still have unsatisfactory names,
but hopefully we are converging on semantics. I am currently working
with the C Xlib owner to see if we can be consistent there.
note especially: window-priority setf, selection-owner setf,
gcontext-clip-mask and setf
gc renamed to gcontext uniformly
:graphics-exposures renamed to :exposures in gcontext-key
display-image-info split out into display-image-lsb-first-p,
display-bitmap-format, and display-pixmap-formats
image-info defstruct split into bitmap-format and pixmap-format
missing default-char added to font-info
defstructs for window-attributes, drawable-geometry, pointer-info, text-extents,
and keyboard-control removed
display-vendor-id renamed to display-vendor
attempt at semantic clarification in with-display
:win-gravity renamed to :gravity in create-window
:backing-bit-planes renamed to :backing-planes in create-window
new accessors:
window-visual, window-class, window-gravity, window-bit-gravity,
window-backing-store, window-backing-planes, window-backing-pixel,
window-save-under, window-colormap, window-colormap-installed-p,
window-map-state, window-all-event-masks, window-event-mask,
window-do-not-propagate-mask, window-override-redirect
new setfs:
window-gravity, window-bit-gravity, window-backing-store, window-backing-planes,
window-backing-pixel, window-save-under, window-event-mask,
window-do-not-propagate-mask, window-override-redirect, window-colormap,
window-cursor
new accessors:
window-root, window-depth, window-x, window-y, window-width, window-height,
window-border-width, pixmap-root, pixmap-depth pixmap-width, pixmap-height,
drawable-root, drawable-depth, drawable-x, drawable-y, drawable-width,
drawable-height, drawable-border-width
new setfs:
window-x, window-y, window-width, window-height, window-border-width,
window-priority
new state-hacking form added: with-state
change-window-attributes, window-attributes, and related multiple value
attribute functions removed
save-set-insert renamed to add-to-save-set
save-set-delete renamed to remove-from-save-set
configure-window removed
drawable-geometry, drawable-size, and drawable-rectangle removed
list-properties return value refined to (sequence keyword)
set-selection-owner recast as a setf
send-event-to-pointer-window and send-event-to-input-focus removed
send-event revised to allow :pointer-window and :input-focus as window,
with display keyword argument required
missing display argument added to ungrab-pointer
with-pointer-grabbed and with-keyboard-grabbed removed
query-pointer changed to return multiple values
global-pointer-position changed to return root window as third value
translate-coordinates defined to return nil when src and dst on different screens
conditional-warp-pointer renamed to warp-pointer-if-inside
text-extents changed to return multiple values
text-bounds removed
text16-extents and text16-width added
:graphics-exposures renamed to :exposure in create-gcontext and with-gcontext
:cache changed to cache-p in create-gcontext, and caching semantics revised
change-gc removed
accessor and setf for clip-mask revised
clear-to-background renamed to clear-area
draw-string-image renamed to draw-image-string
draw-string-image16 renamed to draw-image-string16
stringable added as legal color in store-colors
device-busy error defined for keyboard-mapping and pointer-mapping setfs
keyboard-control changed to return multiple values
acceleration changed from rational to number in change-pointer-control
optional timeout value in seconds added to event-listen
next-event renamed to process-event
force-p renamed to force-output-p in process-event and event-case
hang-p changed to timeout in seconds in process-event and event-case
(keyword var) form allowed in event-case arguments
queue-event-locally renamed to queue-event
event-queue-length removed
event-code changed to event-key in queue-event
∂11-May-87 1655 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU it really was version 3 ...
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 16:55:18 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 11 May 87 19:41-EDT
Date: Mon, 11 May 87 19:43 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: it really was version 3 ...
To: cl-windows@sail.stanford.edu
Message-ID: <870511194336.7.RWS@KILLINGTON.LCS.MIT.EDU>
... despite the comment internally that labelled it Version 2.
∂12-May-87 0506 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU CLX 3: part 1 of 2 [First attempt bounced with "message too large"]
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87 05:06:11 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 May 87 08:03-EDT
Date: Tue, 12 May 87 08:05 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX 3: part 1 of 2 [First attempt bounced with "message too large"]
To: cl-windows@sail.stanford.edu
Message-ID: <870512080534.8.RWS@KILLINGTON.LCS.MIT.EDU>
;;; -*- Mode: LISP; Syntax: Common-lisp; Package: (XLIB (CL)); Base: 10; Lowercase: Yes -*-
;; Draft Version 3
;; Author:
;; Robert W. Scheifler
;; Laboratory for Computer Science
;; 545 Technology Square, Room 418
;; Cambridge, MA 02139
;; rws@zermatt.lcs.mit.edu
;; Contributors:
;; Dan Cerys, Texas Instruments
;; Scott Fahlman, CMU
;; Kerry Kimbrough, Texas Instruments
;; Chris Lindblad, MIT
;; Rob MacLachlan, CMU
;; Mike McMahon, Symbolics
;; David Moon, Symbolics
;; LaMott Oren, Texas Instruments
;; Daniel Weinreb, Symbolics
;; John Wroclawski, MIT
;; Richard Zippel, Symbolics
;; Note: all of the following is in the package XLIB.
;; Note: various perversions of the CL type system are used below.
;; Examples: (list elt-type) (sequence elt-type)
(proclaim '(declaration arglist values))
;; Note: if you have read the Version 11 protocol document or C Xlib manual, most of
;; the relationships should be fairly obvious. We have no intention of writing yet
;; another moby document for this interface.
;; Types employed: display, window, pixmap, cursor, font, gcontext, colormap, color.
;; These types are defined solely by a functional interface; we do not specify
;; whether they are implemented as structures or flavors or ... Although functions
;; below are written using DEFUN, this is not an implementation requirement (although
;; it is a requirement that they be functions as opposed to macros or special forms).
;; It is unclear whether with-slots in the Common Lisp Object System must work on
;; them.
;; Windows, pixmaps, cursors, fonts, gcontexts, and colormaps are all represented as
;; compound objects, rather than as integer resource-ids. This allows applications
;; to deal with multiple displays without having an explicit display argument in the
;; most common functions. Every function uses the display object indicated by the
;; first argument that is or contains a display; it is an error if arguments contain
;; different displays, and predictable results are not guaranteed.
;; Each of window, pixmap, cursor, font, gcontext, and colormap have the following
;; five functions:
(defun make-<mumble> (display resource-id)
;; This function should almost never be called by applications, except in handling
;; events. To minimize consing in some implementations, this may use a cache in
;; the display. Make-gcontext creates with :cache-p nil. Make-font creates with
;; cache-p true.
(declare (type display display)
(type integer resource-id)
(values <mumble>)))
(defun <mumble>-display (<mumble>)
(declare (type <mumble> <mumble>)
(values display)))
(defun <mumble>-id (<mumble>)
(declare (type <mumble> <mumble>)
(values integer)))
(defun <mumble>-equal (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)))
(defun <mumble>-p (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)
(values boolean)))
;; The following functions are provided by color objects:
;; The intention is that IHS and YIQ and CYM interfaces will also exist. Note that
;; we are explicitly using a different spectrum representation than what is actually
;; transmitted in the protocol.
(defun make-color (&key red green blue &allow-other-keys) ; for expansion
(declare (type (number 0 1) red green blue)
(values color)))
(defun color-rgb (color)
(declare (type color color)
(values red green blue)))
(defun color-red (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-green (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-blue (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(deftype resource-id () 'integer)
(deftype drawable () '(or window pixmap))
;; Atoms are accepted as strings or symbols, and are always returned as keywords.
;; Protocol-level integer atom ids are hidden, using a cache in the display object.
(deftype xatom () '(or string symbol))
(deftype stringable () '(or string symbol))
(deftype fontable () '(or stringable font))
;; Nil stands for CurrentTime.
(deftype timestamp () '(or null integer))
(deftype bit-gravity () '(member :forget :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype win-gravity () '(member :unmap :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype grab-status ()
'(member :success :already-grabbed :frozen :invalid-time :not-viewable))
(deftype boolean () '(or null (not null)))
;; An association list.
(deftype alist (key-type-and-name datum-type-and-name) 'list)
;; A sequence, containing zero or more repetitions of the given elements,
;; with the elements expressed as (type name).
(deftype repeat-seq (&rest elts) 'sequence)
(deftype point-seq () '(repeat-seq (integer x) (integer y)))
(deftype seg-seq () '(repeat-seq (integer x1) (integer y1) (integer x2) (integer y2)))
(deftype rect-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)))
;; Note that we are explicitly using a different angle representation than what
;; is actually transmitted in the protocol.
(deftype angle () `(number ,(* -2 pi) ,(* 2 pi)))
(deftype arc-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)
(angle angle1) (angle angle2)))
(deftype event-mask-class ()
'(member :key-press :key-release :owner-grab-button :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :exposure :visibility-change
:structure-notify :resize-redirect :substructure-notify :substructure-redirect
:focus-change :property-change :colormap-change :keymap-state))
(deftype event-mask ()
'(or integer (list event-mask-class)))
(deftype pointer-event-mask-class ()
'(member :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :keymap-state))
(deftype pointer-event-mask ()
'(or integer (list pointer-event-mask-class)))
(deftype device-event-mask-class ()
'(member :key-press :key-release :button-press :button-release :pointer-motion
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion))
(deftype device-event-mask ()
'(or integer (list device-event-mask-class)))
(deftype modifier-key ()
'(member :shift :caps-lock :control :mod-1 :mod-2 :mod-3 :mod-4 :mod-5))
(deftype modifier-mask ()
'(or (member :any) integer (list modifier-key)))
(deftype state-mask-key ()
'(or modifier-key (member :button-1 :button-2 :button-3 :button-4 :button-5)))
(deftype gcontext-key ()
'(member :function :plane-mask :foreground :background
:line-width :line-style :cap-style :join-style :fill-style :fill-rule
:arc-mode :tile :stipple :ts-x :ts-y :font :subwindow-mode
:exposures :clip-x :clip-y :clip-mask :clip-ordering
:dash-offset :dashes))
(deftype event-key ()
'(member :key-press :key-release :button-press :button-release :motion-notify
:enter-notify :leave-notify :focus-in :focus-out :keymap-notify
:exposure :graphics-exposure :no-exposure :visibility-notify
:create-notify :destroy-notify :unmap-notify :map-notify :map-request
:reparent-notify :configure-notify :gravity-notify :resize-request
:configure-request :circulate-notify :circulate-request :property-notify
:selection-clear :selection-request :selection-notify
:colormap-notify :client-message))
(deftype error-key ()
'(member :access :alloc :atom :colormap :cursor :drawable :font :gcontext :id-choice
:illegal-request :implementation :length :match :name :pixmap :property
:value :window))
(deftype draw-direction ()
'(member :left-to-right :right-to-left))
(defstruct bitmap-format
(unit <unspec> :type (member 8 16 32))
(pad <unspec> :type (member 8 16 32))
(lsb-first-p <unspec> :type boolean))
(defstruct pixmap-format
(depth <unspec> :type integer)
(bits-per-pixel <unspec> :type (member 4 8 16 32))
(pad <unspec> :type (member 8 16 32)))
(defstruct visual-info
(id <unspec> :type integer)
(class <unspec> :type (member :static-gray :static-color :true-color
:gray-scale :pseudo-color :direct-color))
(red-mask <unspec> :type integer)
(green-mask <unspec> :type integer)
(blue-mask <unspec> :type integer)
(bits-per-rgb <unspec> :type integer)
(colormap-entries <unspec> :type integer))
(defstruct screen
(root <unspec> :type window)
(device <unspec> :type integer)
(width <unspec> :type integer)
(height <unspec> :type integer)
(width-in-millimeters <unspec> :type integer)
(height-in-millimeters <unspec> :type integer)
(depths <unspec> :type (alist (integer depth) ((list visual-info) visuals)))
(root-depth <unspec> :type integer)
(root-visual <unspec> :type integer)
(default-colormap <unspec> :type colormap)
(white-pixel <unspec> :type integer)
(black-pixel <unspec> :type integer)
(min-installed-maps <unspec> :type integer)
(max-installed-maps <unspec> :type integer)
(backing-stores <unspec> :type (member :never :when-mapped :always))
(save-unders-p <unspec> :type boolean)
(event-mask-at-open <unspec> :type integer))
;; To allow efficient storage representations, the type char-info is not
;; required to be a structure.
(defun char-left-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-right-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-width (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-ascent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-descent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-attributes (char-info)
(declare (type char-info char-info)
(values integer)))
;; The list contains alternating keywords and integers.
(deftype font-props () 'list)
(defstruct font-info
(name <unspec> :type string)
(direction <unspec> :type draw-direction)
(min-char <unspec> :type integer)
(max-char <unspec> :type integer)
(min-byte1 <unspec> :type integer)
(max-byte1 <unspec> :type integer)
(min-byte2 <unspec> :type integer)
(max-byte2 <unspec> :type integer)
(all-chars-exist-p <unspec> :type boolean)
(default-char <unspec> :type integer)
(min-bounds <unspec> :type char-info)
(max-bounds <unspec> :type char-info)
(ascent <unspec> :type integer)
(descent <unspec> :type integer)
(properties <unspec> :type font-props))
(defun open-display (host &key (display 0) protocol)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; and protocol are not constrained, and will likely be very system dependent. The
;; default protocol is system specific. Authorization, if any, is assumed to come
;; from the environment somehow.
(declare (type integer display)
(values display)))
(defun display-protocol-version (display)
;; Values are integers.
(declare (type display display)
(values major minor)))
(defun display-vendor (display)
;; Values are string and integer
(declare (type display display)
(values name release)))
(defun display-image-lsb-first-p (display)
(declare (type display display)
(values boolean)))
(defun display-bitmap-formap (display)
(declare (type display display)
(values bitmap-format)))
(defun display-pixmap-formats (display)
(declare (type display display)
(values (list pixmap-formats))))
(defun display-roots (display)
(declare (type display display)
(values (list screen))))
(defun display-keyboard (display)
(declare (type display display)
(values integer)))
(defun display-pointer (display)
(declare (type display display)
(values integer)))
(defun display-motion-buffer-size (display)
(declare (type display display)
(values integer)))
(defun display-max-request-length (display)
(declare (type display display)
(values integer)))
(defun close-display (display)
(declare (type display display)))
(defun display-error-handler (display)
(declare (type display display)
(values handler)))
(defsetf display-error-handler (display) (handler)
;; All errors (synchronous and asynchronous) are processed by calling an error
;; handler in the display. If handler is a sequence it is expected to contain
;; handler functions specific to each error; the error code is used to index the
;; sequence, fetching the appropriate handler. Any results returned by the handler
;; are ignored; it is assumed the handler either takes care of the error
;; completely, or else signals. For all core errors, the keyword/value argument
;; pairs are:
;; :display display
;; :error-key error-key
;; :major integer
;; :minor integer
;; :sequence integer
;; :current-sequence integer
;; For :colormap, :cursor, :drawable, :font, :gcontext, :id-choice, :pixmap, and
;; :window errors another pair is:
;; :resource-id integer
;; For :atom errors, another pair is:
;; :atom-id integer
;; For :value errors, another pair is:
;; :value integer
(declare (type display display)
(type (or (sequence (function (&rest key-vals)))
(function (&rest key-vals)))
handler)))
(defmacro define-condition (name base &body items)
;; just a place-holder here for the real thing
)
(define-condition request-error error
display
major
minor
sequence
current-sequence)
(defun default-error-handler (&rest key-vals)
;; The default display-error-handler.
;; It signals the conditions listed below.
)
(define-condition resource-error request-error
resource-id)
(define-condition access-error request-error)
(define-condition alloc-error request-error)
(define-condition atom-error request-error
atom-id)
(define-condition colormap-error resource-error)
(define-condition cursor-error resource-error)
(define-condition drawable-error resource-error)
(define-condition font-error resource-error)
(define-condition gcontext-error resource-error)
(define-condition id-choice-error resource-error)
(define-condition illegal-request-error request-error)
(define-condition implementation-error request-error)
(define-condition length-error request-error)
(define-condition match-error request-error)
(define-condition name-error request-error)
(define-condition pixmap-error resource-error)
(define-condition property-error request-error)
(define-condition value-error request-error
value)
(define-condition window-error resource-error)
(defmacro with-display ((display) &body body)
;; This macro is for use in a multi-process environment. It provides exclusive
;; access to the local display object for multiple request generation. It need not
;; provide immediate exclusive access for replies; that is, if another process is
;; waiting for a reply (while not in a with-display), then synchronization need not
;; (but can) occur immediately. Except where noted, all routines effectively
;; contain an implicit with-display where needed, so that correct synchronization
;; is always provided at the interface level on a per-call basis. Nested uses of
;; this macro will work correctly. This macro does not prevent concurrent event
;; processing; see with-event-queue.
)
(defun display-force-output (display)
;; Output is normally buffered; this forces any buffered output.
(declare (type display display)))
(defun display-finish-output (display)
;; Forces output, then causes a round-trip to ensure that all possible errors and
;; events have been received.
(declare (type display display)))
(defun display-after-function (display)
;; setf'able
;; If defined, called after every protocol request is generated, even those inside
;; explicit with-display's, but never called from inside the after-function itself.
;; The function is called inside the effective with-display for the associated
;; request. Default value is nil. Can be set, for example, to
;; #'display-force-output or #'display-finish-output.
(declare (type display display)
(values (or null (function (display))))))
(defun create-window (&key parent x y width height (depth 0) (border-width 0)
(class :copy) (visual :copy)
background border gravity bit-gravity
backing-store backing-planes backing-pixel save-under
event-mask do-not-propagate-mask override-redirect
colormap cursor)
;; Display is obtained from parent. Only non-nil attributes are passed on in the
;; request: the function makes no assumptions about what the actual protocol
;; defaults are. Width and height are the inside size, excluding border.
(declare (type window parent)
(type integer x y width height depth border-width)
(type (member :copy :input-output :input-only) class)
(type (or (member :copy) visual) visual)
(type (or null (member :none :parent-relative) integer pixmap) background)
(type (or null (member :copy) integer pixmap) border)
(type (or null win-gravity) gravity)
(type (or null bit-gravity) bit-gravity)
(type (or null (member :not-useful :when-mapped :always) backing-store))
(type (or null integer) backing-planes backing-pixel)
(type (or null event-mask) event-mask)
(type (or null device-event-mask) do-not-propagate-mask)
(type (or null (member :on :off)) save-under override-redirect)
(type (or null (member :copy) colormap) colormap)
(type (or null (member :none) cursor) cursor)
(values window)))
(defun window-root (window)
(declare (type window window)
(values window)))
(defun window-x (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-y (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-width (window)
;; setf'able
;; Inside width, excluding border.
(declare (type window window)
(values integer)))
(defun window-height (window)
;; setf'able
;; Inside height, excluding border.
(declare (type window window)
(values integer)))
(defun window-depth (window)
(declare (type window window)
(values integer)))
(defun window-border-width (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-class (window)
(declare (type window window)
(values (member :input-output :input-only))))
(defun window-visual (window)
(declare (type window window)
(values integer)))
(defsetf window-background (window) (background)
(declare (type window window)
(type (or (member :none :parent-relative) integer pixmap) background)))
(defsetf window-border (window) (border)
(declare (type window window)
(type (or (member :copy) integer pixmap) border)))
(defun window-gravity (window)
;; setf'able
(declare (type window window)
(values win-gravity)))
(defun window-bit-gravity (window)
;; setf'able
(declare (type window window)
(values bit-gravity)))
(defun window-backing-store (window)
;; setf'able
(declare (type window window)
(values (member :not-useful :when-mapped :always))))
(defun window-backing-planes (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-backing-pixel (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-save-under (window)
;; setf'able
(declare (type window window)
(values (member :on :off))))
(defun window-event-mask (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-do-not-propagate-mask (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-override-redirect (window)
;; setf'able
(declare (type window window)
(values (member :on :off))))
(defun window-colormap (window)
(declare (type window window)
(values (or null colormap))))
(defsetf window-colormap (window) (colormap)
(declare (type window window)
(type (or (member :copy) colormap) colormap)))
(defsetf window-cursor (window) (cursor)
(declare (type window window)
(type (or (member :none) cursor) cursor)))
(defun window-colormap-installed-p (window)
(declare (type window window)
(values boolean)))
(defun window-all-event-masks (window)
(declare (type window window)
(values integer)))
(defun window-map-state (window)
(declare (type window window)
(values (member :unmapped :unviewable :viewable))))
(defsetf window-priority (window &optional sibling) (mode)
;; A bit strange, but retains setf form.
(declare (type window window)
(type (or null window) sibling)
(type (member :above :below :top-if :bottom-if :opposite) mode)))
(defmacro with-state ((drawable) &body body)
;; Allows a consistent view to be obtained of data returned by GetWindowAttributes
;; and GetGeometry, and allows a coherent update using ChangeWindowAttributes and
;; ConfigureWindow. The body is not surrounded by a with-display. Within the
;; indefinite scope of the body, on a per-process basis in a multi-process
;; environment, the first call within an Accessor Group on the specified drawable
;; (the object, not just the variable) causes the complete results of the protocol
;; request to be retained, and returned in any subsequent accessor calls. Calls
;; within a Setf Group are delayed, and executed in a single request on exit from
;; the body. In addition, if a call on a function within an Accessor Group follows
;; a call on a function in the corresponding Setf Group, then all delayed setfs for
;; that group are executed, any retained accessor information for that group is
;; discarded, the corresponding protocol request is (re)issued, and the results are
;; (again) retained, and returned in any subsequent accessor calls.
;; Accessor Group A (for GetWindowAttributes):
;; window-visual, window-class, window-gravity, window-bit-gravity,
;; window-backing-store, window-backing-planes, window-backing-pixel,
;; window-save-under, window-colormap, window-colormap-installed-p,
;; window-map-state, window-all-event-masks, window-event-mask,
;; window-do-not-propagate-mask, window-override-redirect
;; Setf Group A (for ChangeWindowAttributes):
;; window-gravity, window-bit-gravity, window-backing-store, window-backing-planes,
;; window-backing-pixel, window-save-under, window-event-mask,
;; window-do-not-propagate-mask, window-override-redirect, window-colormap,
;; window-cursor
;; Accessor Group G (for GetGeometry):
;; window-root, window-depth, window-x, window-y, window-width, window-height,
;; window-border-width, pixmap-root, pixmap-depth pixmap-width, pixmap-height,
;; drawable-root, drawable-depth, drawable-x, drawable-y, drawable-width,
;; drawable-height, drawable-border-width
;; Setf Group G (for ConfigureWindow):
;; window-x, window-y, window-width, window-height, window-border-width,
;; window-priority
)
(defun destroy-window (window)
(declare (type window window)))
(defun destroy-subwindows (window)
(declare (type window window)))
(defun add-to-save-set (window)
(declare (type window window)))
(defun remote-from-save-set (window)
(declare (type window window)))
(defun reparent-window (window parent x y)
(declare (type window window parent)
(type integer x y)))
(defun map-window (window)
(declare (type window window)))
(defun map-subwindows (window)
(declare (type window window)))
(defun unmap-window (window)
(declare (type window window)))
(defun unmap-subwindows (window)
(declare (type window window)))
(defun circulate-window-up (window)
(declare (type window window)))
(defun circulate-window-down (window)
(declare (type window window)))
(defun drawable-root (drawable)
(declare (type drawable drawable)
(values drawable)))
(defun drawable-depth (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-x (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-y (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-width (drawable)
;; For windows, inside width, excluding border.
(declare (type drawable drawable)
(values integer)))
(defun drawable-height (drawable)
;; For windows, inside height, excluding border.
(declare (type drawable drawable)
(values integer)))
(defun drawable-border-width (drawable)
(declare (type drawable drawable)
(values integer)))
(defun query-tree (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence window) parent root)))
(defun change-property (window property data type format
&key (mode :replace) (start 0) end transform)
;; Start and end affect sub-sequence extracted from data.
;; Transform is applied to each extracted element.
(declare (type window window)
(type xatom property type)
(type (member 8 16 32) format)
(type sequence data)
(type (member :replace :prepend :append) mode)
(type integer start)
(type (or null integer) end)
(type (or null (function (t) integer)) transform)))
(defun delete-property (window property)
(declare (type window window)
(type xatom property)))
(defun get-property (window property
&key type (start 0) end delete-p (result-type 'list) transform)
;; Transform is applied to each integer retrieved.
(declare (type window window)
(type xatom property)
(type (or null xatom) type)
(type integer start)
(type (or null integer) end)
(type boolean delete-p)
(type type result-type)
(type (or null (function (integer) t)) transform)
(values data type format bytes-after)))
(defun rotate-properties (window properties &optional (delta 1))
;; Postive rotates left, negative rotates right (opposite of actual protocol request).
(declare (type window window)
(type (sequence xatom) properties)
(type integer delta)))
(defun list-properties (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence keyword))))
;; Although atom-ids are not visible in the normal user interface, atom-ids might
;; appear in window properties and other user data, so conversion hooks are needed.
(defun intern-atom (display name)
(declare (type display display)
(type xatom name)
(values integer)))
(defun find-atom (display name)
(declare (type display display)
(type xatom name)
(values (or null integer))))
(defun atom-name (display atom-id)
(declare (type display display)
(type integer atom-id)
(values keyword)))
(defun selection-owner (display selection)
(declare (type display display)
(type xatom selection)
(values (or null window))))
(defsetf selection-owner (display selection &optional time) (owner)
;; A bit strange, but retains setf form.
(declare (type display display)
(type xatom selection)
(type (or null window) owner)
(type timestamp time)))
(defun convert-selection (selection type requestor &optional property time)
(declare (type xatom selection type)
(type window requestor)
(type (or null xatom) property)
(type timestamp time)))
(defun send-event (window event-key event-mask &rest args
&key propagate-p display &allow-other-keys)
;; Additional arguments depend on event-key, and are as specified further below
;; with declare-event, except that both resource-ids and resource objects are
;; accepted in the event components. The display argument is only required if the
;; window is :pointer-window or :input-focus.
(declare (type (or window (member :pointer-window :input-focus)) window)
(type event-key event-key)
(type event-mask event-mask)
(type boolean propagate-p)
(type (or null display) display)))
(defun grab-pointer (window event-mask
&key owner-p sync-pointer-p sync-keyboard-p confine-to cursor time)
(declare (type window window)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)
(type timestamp time)
(values grab-status)))
(defun ungrab-pointer (display &key time)
(declare (type display display)
(type timestamp time)))
(defun grab-button (window button event-mask
&key (modifiers 0)
owner-p sync-pointer-p sync-keyboard-p confine-to cursor)
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)))
(defun ungrab-button (window button &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)))
(defun change-active-pointer-grab (display event-mask &optional cursor time)
(declare (type display display)
(type pointer-event-mask event-mask)
(type (or null cursor) cursor)
(type timestamp time)))
(defun grab-keyboard (window &key owner-p sync-pointer-p sync-keyboard-p time)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type timestamp time)
(values grab-status)))
(defun ungrab-keyboard (display &key time)
(declare (type display display)
(type timestamp time)))
(defun grab-key (window key &key (modifiers 0) owner-p sync-pointer-p sync-keyboard-p)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun ungrab-key (window key &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun allow-events (display mode &optional time)
(declare (type display display)
(type (member :async-pointer :sync-pointer :reply-pointer
:async-keyboard :sync-keyboard :replay-keyboard)
mode)
(type timestamp time)))
(defun grab-server (display)
(declare (type display display)))
(defun ungrab-server (display)
(declare (type display display)))
(defmacro with-server-grabbed ((display) &body body)
;; The body is not surrounded by a with-display.
)
∂12-May-87 0507 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU CLX 3: part 2 of 2
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87 05:06:45 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 May 87 08:04-EDT
Date: Tue, 12 May 87 08:06 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX 3: part 2 of 2
To: cl-windows@sail.stanford.edu
Message-ID: <870512080611.9.RWS@KILLINGTON.LCS.MIT.EDU>
(defun query-pointer (window)
(declare (type window window)
(values x y same-screen-p child mask root-x root-y root)))
(defun pointer-position (window)
(declare (type window window)
(values x y same-screen-p)))
(defun global-pointer-position (display)
(declare (type display display)
(values root-x root-y root)))
(defun motion-events (window &key start stop (result-type 'list))
(declare (type window window)
(type timestamp start stop)
(type type result-type)
(values (repeat-seq (integer x) (integer y) (timestamp time)))))
(defun translate-coordinates (src src-x src-y dst)
;; If src and dst are not on the same screen, nil is returned.
(declare (type window src)
(type integer src-x src-y)
(type window dst)
(values dst-x dst-y child)))
(defun warp-pointer (dst dst-x dst-y)
(declare (type window dst)
(type integer dst-x dst-y)))
(defun warp-pointer-if-inside (dst dst-x dst-y src src-x src-y
&optional src-width src-height)
;; Passing in a zero src-width or src-height is a no-op. A null src-width or
;; src-height translates into a zero value in the protocol request.
(declare (type window dst src)
(type integer dst-x dst-y src-x src-y)
(type (or null integer) src-width src-height)))
(defun set-input-focus (display focus revert-to &optional time)
;; Setf ought to allow multiple values.
(declare (type display display)
(type (or (member :none :pointer-root) window) focus)
(type (member :none :parent :pointer-root) revert-to)
(type timestamp time)))
(defun input-focus (display)
(declare (type display display)
(values focus revert-to)))
(defun query-keymap (display)
(declare (type display display)
(values (bit-vector 256))))
(defun open-font (display name &optional (cache-p t))
;; Font objects may be cached and reference counted locally within the display
;; object. This function might not execute a with-display if the font is cached.
;; The protocol QueryFont request happens on-demand under the covers. If cache-p
;; is nil, QueryFont results are never cached locally.
(declare (type display display)
(type stringable name)
(type boolean cache-p)
(values font)))
(defun font-cache-p (font)
;; setf'able
(declare (type font font)
(values boolean)))
(defun font-font-info (font)
(declare (type font font)
(values font-info)))
;; For each component (<name> <unspec> :type <type>) of font-info,
;; there is a corresponding function:
(defun font-<name> (font)
(declare (type font font)
(values <type>)))
(defun font-property (font name)
(declare (type font font)
(type keyword name)
(values (or null integer))))
(defun font-char-infos (font)
(declare (type font font)
(values (array char-info))))
(defun font-char-info (font char)
(declare (type font font)
(type integer char)
(values (or null char-info))))
(defun font-char16-info (font first-byte second-byte)
(declare (type font font)
(type integer first-byte second-byte)
(values (or null char-info))))
(defun close-font (font)
;; This might not generate a protocol request if the font is reference counted
;; locally.
(declare (type font font)))
(defun text-extents (font string)
(declare (type (or font gcontext) font)
(type string string)
(values width ascent descent left right font-ascent font-descent direction)))
(defun text16-extents (font array &key bytes-p)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type (or font gcontext) font)
(type array array)
(type boolean bytes-p)
(values width ascent descent left right font-ascent font-descent direction)))
(defun text-width (font string)
(declare (type (or font gcontext) font)
(type string string)
(values integer)))
(defun text16-width (font array &key bytes-p)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type (or font gcontext) font)
(type array array)
(type boolean bytes-p)
(values integer)))
(defun list-fonts (display pattern &key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence string))))
(defun list-fonts-with-info (display pattern &key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence font-info))))
(defun font-path (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence (or string pathname)))))
(defsetf font-path (display) (paths)
(declare (type display display)
(type (sequence (or string pathname)) paths)))
(defun create-pixmap (&key width height depth drawable)
(declare (type integer width height depth)
(type drawable drawable)
(values pixmap)))
(defun pixmap-root (pixmap)
(declare (type pixmap pixmap)
(values pixmap)))
(defun pixmap-depth (pixmap)
(declare (type pixmap pixmap)
(values integer)))
(defun pixmap-width (pixmap)
(declare (type pixmap pixmap)
(values integer)))
(defun pixmap-height (pixmap)
(declare (type pixmap pixmap)
(values integer)))
(defun free-pixmap (pixmap)
(declare (type pixmap pixmap)))
(defun create-gcontext (&key drawable function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
exposures clip-x clip-y clip-mask clip-ordering
dash-offset dashes
(cache-p t))
;; Only non-nil components are passed on in the request, but for effective caching
;; assumptions have to be made about what the actual protocol defaults are. For
;; all gcontext components, a value of nil causes the default gcontext value to be
;; used. For clip-mask, this implies that an empty rect-seq cannot be represented
;; as a list. Note: use of stringable as font will cause an implicit open-font.
;; Note: papers over protocol SetClipRectangles and SetDashes special cases. If
;; cache-p is true, then gcontext state is cached locally, and changing a gcontext
;; component will have no effect unless the new value differs from the cached
;; value. Component changes (setfs and with-gcontext) are always deferred
;; regardless of the cache mode, and sent over the protocol only when required by a
;; local operation or by an explicit call to force-gcontext-changes.
(declare (type drawable drawable)
(type (or null boole-constant) function)
(type (or null integer) plane-mask foreground background line-width
ts-x ts-y clip-x clip-y dash-offset)
(type (or null (member :solid :dash :double-dash)) line-style)
(type (or null (member :not-last :butt :round :projecting)) cap-style)
(type (or null (member :miter :round :bevel)) join-style)
(type (or null (member :solid :tiled :opaque-stippled :stippled)) fill-style)
(type (or null (member :even-odd :winding)) fill-rule)
(type (or null (member :chord :pie-slice)) arc-mode)
(type (or null pixmap) tile stipple)
(type (or null fontable) font)
(type (or null (member :clip-by-children :include-inferiors)) subwindow-mode)
(type (or null (member :on :off)) exposures)
(type (or null (member :none) pixmap rect-seq) clip-mask)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or null (or integer (sequence integer))) dashes)
(type (or null integer) dash-offset)
(type boolean cache)
(values gcontext)))
;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type <type> <name>), there is an accessor:
(defun gcontext-<name> (gcontext)
;; The value will be nil if the last value stored is unknown (e.g., the cache was
;; off, or the component was copied from a gcontext with unknown state).
(declare (type gcontext gcontext)
(values <type>)))
;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type (or null <type>) <name>), there is a setf for the corresponding accessor:
(defsetf gcontext-<name> (gcontext) (value)
(declare (type gcontext gcontext)
(type <type> value)))
(defun gcontext-clip-mask (gcontext)
(declare (type gcontext gcontext)
(values (or null (member :none) pixmap rect-seq)
(or null (member :unsorted :y-sorted :yx-sorted :yx-banded)))))
(defsetf gcontext-clip-mask (gcontext &optional ordering) (clip-mask)
;; Is nil illegal here, or is it transformed to a vector?
;; A bit strange, but retains setf form.
(declare (type gcontext gcontext)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or (member :none) pixmap rect-seq) clip-mask)))
(defun force-gcontext-changes (gcontext)
;; Force any delayed changes.
(declare (type gcontext gcontext)))
(defmacro with-gcontext ((gcontext &key
function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
exposures clip-x clip-y clip-mask clip-ordering
dashes dash-offset)
&body body)
;; Changes gcontext components within the dynamic scope of the body (i.e.,
;; indefinite scope and dynamic extent), on a per-process basis in a multi-process
;; environment. The body is not surrounded by a with-display. If cache-p is nil
;; or the some component states are unknown, this will implement save/restore by
;; creating a temporary gcontext and doing copy-gcontext-components to and from it.
)
(defun copy-gcontext-components (src dst &rest keys)
(declare (type gcontext src dst)
(type (list gcontext-key) keys)))
(defun copy-gcontext (src dst)
(declare (type gcontext src dst))
;; Copies all components.
)
(defun free-gcontext (gcontext)
(declare (type gcontext gcontext)))
(defun clear-area (window &key (x 0) (y 0) width height exposures-p)
;; Passing in a zero width or height is a no-op. A null width or height translates
;; into a zero value in the protocol request.
(declare (type window window)
(type integer x y)
(type (or null integer) width height)
(type boolean exposures-p)))
(defun copy-area (src gcontext src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gcontext gcontext)
(type integer src-x src-y width height dst-x dst-y)))
(defun copy-plane (src gcontext plane src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gcontext gcontext)
(type integer src-x src-y plane width height dst-x dst-y)))
(defun draw-point (drawable gcontext x y)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)))
(defun draw-points (drawable gcontext points &optional relative-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type point-seq points)
(type boolean relative-p)))
(defun draw-line (drawable gcontext x1 y1 x2 y2 &optional relative-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x1 y1 x2 y2)
(type boolean relative-p)))
(defun draw-lines (drawable gcontext points &key relative-p fill-p (shape :complex))
(declare (type drawable drawable)
(type gcontext gcontext)
(type point-seq points)
(type boolean relative-p fill-p)
(type (member :complex :non-convex :convex) shape)))
(defun draw-segments (drawable gcontext segments)
(declare (type drawable drawable)
(type gcontext gcontext)
(type seg-seq segments)))
(defun draw-rectangle (drawable gcontext x y width height &optional fill-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y width height)
(type boolean fill-p)))
(defun draw-rectangles (drawable gcontext rectangles &optional fill-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type rect-seq rectangles)
(type boolean fill-p)))
(defun draw-arc (drawable gcontext x y width height angle1 angle2 &optional fill-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y width height angle1 angle2)
(type boolean fill-p)))
(defun draw-arcs (drawable gcontext arcs &optional fill-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type arc-seq arcs)
(type boolean fill-p)))
;; The following image routines are bare minimum. It may be useful to define some
;; form of "image" object to hide representation details and format conversions. It
;; also may be useful to provide stream-oriented interfaces for reading and writing
;; the data.
(defun put-raw-image (drawable gcontext data
&key (start 0) depth x y width height (left-pad 0) format)
;; Data must be a sequence of 8-bit quantities, already in the appropriate format
;; for transmission; the caller is responsible for all byte and bit swapping and
;; compaction. Start is the starting index in data; the end is computed from the
;; other arguments.
(declare (type drawable drawable)
(type gcontext gcontext)
(type (sequence integer) data)
(type integer start depth x y width height left-pad)
(type (member :bitmap :xy-pixmap :z-pixmap) format)))
(defun get-raw-image (drawable &key data (start 0) x y width height (plane-mask -1) format
(result-type '(vector (unsigned-byte 8))))
;; If data is given, it is modified in place (and returned), otherwise a new
;; sequence is created and returned, with a size computed from the other arguments
;; and the returned depth. The sequence is filled with 8-bit quantities, in
;; transmission format; the caller is responsible for any byte and bit swapping and
;; compaction required for further local use.
(declare (type drawable drawable)
(type (or null (sequence integer)) data)
(type integer start x y width height plane-mask)
(type (member :xy-format z-format) format)
(values (sequence integer) depth visual)))
(defun draw-string (drawable gcontext x y string &key (start 0) end)
;; For 8-bit indexes only.
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type (or null integer) end)))
(defun draw-text (drawable gcontext items)
;; For 8-bit indexes only.
;; Items is a flat sequence containing both triples and pairs of the form:
;; (integer x) (integer y) (string string)
;; :font (fontable font)
(declare (type drawable drawable)
(type gcontext gcontext)
(type sequence items)))
(defun draw-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached. If bytes-p is nil,
;; then array should be an array of integers to be treated as 16-bit quantities,
;; otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type array array)
(type boolean bytes-p)))
(defun draw-text16 (drawable gcontext items &key bytes-p)
;; Items is a flat sequence containing both triples and pairs of the form:
;; (integer x) (integer y) (array array)
;; :font (fontable font)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a (sub)string of even length,
;; treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type sequence items)
(type boolean bytes-p)
(type (or null integer) end)))
(defun draw-image-string (drawable gcontext x y string &key (start 0) end)
;; For 8-bit indexes only.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type (or null integer) end)))
(defun draw-image-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a (sub)string of even length,
;; treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type array array)
(type boolean bytes-p)
(type (or null integer) end)))
(defun create-colormap (visual window &optional alloc-p)
(declare (type integer visual)
(type window window)
(type boolean alloc-p)
(values colormap)))
(defun free-colormap (colormap)
(declare (type colormap colormap)))
(defun copy-colormap-and-free (colormap)
(declare (type colormap colormap)
(values colormap)))
(defun install-colormap (colormap)
(declare (type colormap colormap)))
(defun uninstall-colormap (colormap)
(declare (type colormap colormap)))
(defun installed-colormaps (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence colormap))))
(defun alloc-color (colormap color)
(declare (type colormap colormap)
(type (or stringable color) color)
(values pixel screen-color exact-color)))
(defun alloc-color-cells (colormap colors &key (planes 0) contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors planes)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) (sequence mask))))
(defun alloc-color-planes (colormap colors
&key (reds 0) (greens 0) (blues 0)
contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors reds greens blues)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) red-mask green-mask blue-mask)))
(defun free-colors (colormap pixels &optional (plane-mask 0))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type integer plane-mask)))
(defun store-color (colormap pixel spec &key (red-p t) (green-p t) (blue-p t))
(declare (type colormap colormap)
(type integer pixel)
(type (or stringable color) spec)
(type boolean red-p green-p blue-p)))
(defun store-colors (colormap specs &key (red-p t) (green-p t) (blue-p t))
;; If stringables are specified for colors, it is unspecified whether all
;; stringables are first resolved and then a single StoreColors protocol request is
;; issued, or whether multiple StoreColors protocol requests are issued.
(declare (type colormap colormap)
(type (repeat-seq (integer pixel) ((or stringable color) color)) specs)
(type boolean red-p green-p blue-p)))
(defun query-colors (colormap pixels &key (result-type 'list))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type type result-type)
(values (sequence color))))
(defun lookup-color (colormap name)
(declare (type colormap colormap)
(type stringable name)
(values screen-color true-color)))
(defun create-cursor (&key source mask x y foreground background)
(declare (type pixmap source)
(type (or null pixmap) mask)
(type integer x y)
(type color foreground background)
(values cursor)))
(defun create-glyph-cursor (&key source-font source-char mask-font mask-char
foreground background)
(declare (type font source-font)
(type integer source-char)
(type (or null font) mask-font)
(type (or null integer) mask-char)
(type color foreground background)
(values cursor)))
(defun free-cursor (cursor)
(declare (type cursor cursor)))
(defun recolor-cursor (cursor foreground background)
(declare (type cursor cursor)
(type color foreground background)))
(defun query-best-cursor (width height display)
(declare (type integer width height)
(type display display)
(values width height)))
(defun query-best-tile (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-best-stipple (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-extension (display name)
(declare (type display display)
(type stringable name)
(values major-opcode first-event first-error)))
(defun list-extensions (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence string))))
(defun keyboard-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(define-condition device-busy error)
(defsetf keyboard-mapping (display) (map)
;; Can signal device-busy.
(declare (type display display)
(type (sequence integer) map)))
(defun change-keyboard-control (display &key key-click-percent
bell-percent bell-pitch bell-duration
led led-mode key auto-repeat-mode)
(declare (type display display)
(type (or null (member :default) integer) key-click-percent
bell-percent bell-pitch bell-duration)
(type (or null integer) led key)
(type (or null (member :on :off)) led-mode)
(type (or null (member :on :off :default)) auto-repeat-mode)))
(defun keyboard-control (display)
(declare (type display display)
(values key-click-percent bell-percent bell-pitch bell-duration
led-mask global-auto-repeat auto-repeats)))
(defun bell (display &optional (percent-from-normal 0))
;; It is assumed that an eventual audio extension to X will provide more complete
;; control.
(declare (type display display)
(type integer percent-from-normal)))
(defun pointer-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(defsetf pointer-mapping (display) (map)
;; Can signal device-busy.
(declare (type display display)
(type (sequence integer) map)))
(defun change-pointer-control (display &key acceleration threshold)
;; Acceleration is rationalized if necessary.
(declare (type display display)
(type (or null (member :default) number) acceleration)
(type (or null (member :default) integer) threshold)))
(defun pointer-control (display)
(declare (type display display)
(values acceleration threshold)))
(defun set-screen-saver (display timeout interval blanking exposures)
;; Setf ought to allow multiple values.
;; Timeout and interval are in seconds, will be rounded to minutes.
(declare (type display display)
(type (or (member :default) integer) timeout interval)
(type (member :yes :no :default) blanking exposures)))
(defun screen-saver (display)
;; Returns timeout and interval in seconds.
(declare (type display display)
(values timeout interval blanking exposures)))
(defun activate-screen-saver (display)
(declare (type display display)))
(defun reset-screen-saver (display)
(declare (type display display)))
(defun add-access-host (display host)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; are not constrained, and will likely be very system dependent.
(declare (type display display)))
(defun remove-access-host (display host)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; are not constrained, and will likely be very system dependent.
(declare (type display display)))
(defun access-hosts (display &key (result-type 'list))
;; The type of host objects returned is not constrained, except that the hosts must
;; be acceptable to add-access-host and remove-access-host.
(declare (type display display)
(type type result-type)
(values (sequence host) enabled-p)))
(defun access-control (display)
;; setf'able
(declare (type display display)
(values boolean)))
(defun close-down-mode (display)
;; setf'able
;; Cached locally in display object.
(declare (type display display)
(values (member :destroy :retain-permanent :retain-temporary))))
(defun kill-client (display resource-id)
(declare (type display display)
(type resource-id resource-id)))
(defun kill-temporary-clients (display)
(declare (type display display)))
(defun make-event-mask (&rest keys)
;; This is only defined for core events.
;; Useful for constructing event-mask, pointer-event-mask, device-event-mask.
(declare (type (list event-mask-class) keys)
(values integer)))
(defun make-event-keys (event-mask)
;; This is only defined for core events.
(declare (type integer event-mask)
(values (list event-mask-class))))
(defun make-state-mask (&rest keys)
;; Useful for constructing modifier-mask, state-mask.
(declare (type (list state-mask-key) keys)
(values integer)))
(defun make-state-keys (state-mask)
(declare (type integer mask)
(values (list state-mask-key))))
(defmacro with-event-queue ((display) &body body)
;; Grants exclusive access to event queue.
)
(defun event-listen (display &optional (timeout 0))
(declare (type display display)
(type (or null number) timeout))
;; Returns the number of events queued locally, if any, else nil. Hangs waiting
;; for events, forever if timeout is nil, else for the specified number of seconds.
)
(defun process-event (display &key handler timeout peek-p discard-p force-output-p)
;; If force-output-p is true, first invokes display-force-output. Invokes handler
;; on each queued event until handler returns non-nil, and that returned object is
;; then returned by process-event. If peek-p is true, then the event is not
;; removed from the queue. If discard-p is true, then events for which handler
;; returns nil are removed from the queue, otherwise they are left in place. Hangs
;; until non-nil is generated for some event, or for the specified timeout (in
;; seconds, if given); however, it is acceptable for an implementation to wait only
;; once on network data, and therefore timeout prematurely. Returns nil on
;; timeout. If handler is a sequence, it is expected to contain handler functions
;; specific to each event class; the event code is used to index the sequence,
;; fetching the appropriate handler. Handler is called with raw resource-ids, not
;; with resource objects. The arguments to the handler are described further below
;; using declare-event.
(declare (type display display)
(type (or (sequence (function (&rest key-vals) t))
(function (&rest key-vals) t))
handler)
(type (or null number) timeout)
(type boolean peek-p)))
(defmacro event-case ((display &key timeout peek-p discard-p force-output-p)
&body clauses)
(declare (arglist (display &key timeout peek-p discard-p force-output-p)
(event-or-events ((&rest args) |...|) &body body) |...|))
;; If force-output-p is true, first invokes display-force-output. Executes the
;; matching clause for each queued event until a clause returns non-nil, and that
;; returned object is then returned by event-case. If peek-p is true, then the
;; event is not removed from the queue. If discard-p is true, then events for
;; which the clause returns nil are removed from the queue, otherwise they are left
;; in place. Hangs until non-nil is generated for some event, or for the specified
;; timeout (in seconds, if given); however, it is acceptable for an implementation
;; to wait only once on network data, and therefore timeout prematurely. Returns
;; nil on timeout. In each clause, event-or-events is an event-key or a list of
;; event-keys (but they need not be typed as keywords) or the symbol t or otherwise
;; (but only in the last clause). The keys are not evaluated, and it is an error
;; for the same key to appear in more than one clause. Args is the list of event
;; components of interest; corresponding values (if any) are bound to variables
;; with these names (i.e., the args are variable names, not keywords, the keywords
;; are derived from the variable names). An arg can also be a (keyword var) form,
;; as for keyword args in a lambda lists. If no t/otherwise clause appears, it is
;; equivalent to having one that returns nil.
)
(defmacro declare-event (event-codes &rest declares)
;; Used to indicate the keyword arguments for handler functions in process-event
;; and event-case. All process-event handlers can have (display display) and
;; (event-key event-key) as keyword arguments, and an event-case clause can also
;; have event-key as an argument.
(declare (arglist event-key-or-keys &rest (type &rest keywords))))
(declare-event (:key-press :key-release :button-press :button-release)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
;; for key-press and key-release, code is the keycode
;; for button-press and button-release, code is the button number
(integer code))
(declare-event :motion-notify
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
(boolean hint-p))
(declare-event (:enter-notify :leave-notify)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
((member :normal :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual) kind)
(boolean focus-p))
(declare-event (:focus-in :focus-out)
(resource-id window)
((member :normal :while-grabbed :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual
:pointer :pointer-root :none)
kind))
(declare-event :keymap-notify
(resource-id window)
((bit-vector 256) keymap))
(declare-event :exposure
(resource-id window)
(integer x y width height)
(boolean last-p))
(declare-event :graphics-exposure
(resource-id drawable)
(integer x y width height major minor)
(boolean last-p))
(declare-event :no-exposure
(resource-id drawable)
(integer major minor))
(declare-event :visibility-notify
(resource-id window)
((member :unobscured :partially-obscured :fully-obscured) state))
(declare-event :create-notify
(resource-id window parent)
(integer x y width height border-width)
(boolean override-redirect-p))
(declare-event :destroy-notify
(resource-id event-window window))
(declare-event :unmap-notify
(resource-id event-window window)
(boolean configure-p))
(declare-event :map-notify
(resource-id event-window window)
(boolean override-redirect-p))
(declare-event :map-request
(resource-id parent window))
(declare-event :reparent-notify
(resource-id event-window window parent)
(integer x y)
(boolean override-redirect-p))
(declare-event :configure-notify
(resource-id event-window window)
(integer x y width height border-width)
((or null resource-id) above-sibling)
(boolean override-redirect-p))
(declare-event :gravity-notify
(resource-id event-window window)
(integer x y))
(declare-event :resize-request
(resource-id window)
(integer width height))
(declare-event :configure-request
(resource-id parent window)
(integer x y width height border-width)
((or null resource-id) above-sibling))
(declare-event :circulate-notify
(resource-id event-window window)
((member :top :bottom) place))
(declare-event :circulate-request
(resource-id parent window)
((member :top :bottom) place))
(declare-event :property-notify
(resource-id window)
(keyword atom)
((member :new-value :deleted) state)
(integer time))
(declare-event :selection-clear
(resource-id window)
(keyword selection)
(integer time))
(declare-event :selection-request
(resource-id window requestor)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :selection-notify
(resource-id window)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :colormap-notify
(resource-id window)
((or null resource-id) colormap)
(boolean new-p installed-p))
(declare-event :client-message
(resource-id window)
((member 8 16 32) format)
((sequence integer) data))
(defun queue-event (display event-key &rest args &key append-p &allow-other-keys)
;; The event is put at the head of the queue if append-p is nil, else the tail.
;; Additional arguments depend on event-key, and are as specified above with
;; declare-event, except that both resource-ids and resource objects are accepted
;; in the event components.
(declare (type display display)
(type event-key event-key)
(type boolean append-p)))
∂13-May-87 1626 Oren%Tilde%ti-csl.csnet@RELAY.CS.NET RE: CLX draft 3 revisions
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 May 87 16:25:55 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac01023; 13 May 87 19:23 EDT
Received: from ti-csl by RELAY.CS.NET id ae09454; 13 May 87 19:17 EDT
Received: from SI (si.ARPA) by tilde id AA27584; Wed, 13 May 87 16:48:28 cdt
Message-Id: <2756929653-5689439@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 13 May 87 16:47:33 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: RE: CLX draft 3 revisions
Since you've got:
drawable-depth, drawable-root, drawable-x, drawable-y, drawable-width,
drawable-height, drawable-border-width
How about getting rid of:
window-depth, window-root, window-x, window-y, window-width,
window-height, window-border-width
and
pixmap-depth, pixmap-root, pixmap-width, pixmap-height
-LaMott
∂13-May-87 1901 harris%hplwhh@hplabs.HP.COM Re: CLX draft 3 revisions
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 13 May 87 19:01:30 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Wed, 13 May 87 18:57:20 pdt
Received: from hplwhh (hplwhh) by hplms1; Wed, 13 May 87 18:56:16 pdt
Return-Path: <harris@hplwhh>
Received: from hplwhh.hpl.hp.com by hplwhh ; Wed, 13 May 87 18:55:42 pdt
Message-Id: <8705140155.AA02460@hplwhh>
To: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
Cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU,
harris%hplwhh@hplabs.HP.COM
Subject: Re: CLX draft 3 revisions
In-Reply-To: Your message of Wed, 13 May 87 16:47:33 -0500.
<2756929653-5689439@SI>
Date: Wed, 13 May 87 18:55:35 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
> Since you've got:
> drawable-depth, drawable-root, drawable-x, drawable-y, drawable-width,
> drawable-height, drawable-border-width
>
> How about getting rid of:
> window-depth, window-root, window-x, window-y, window-width,
> window-height, window-border-width
> and
> pixmap-depth, pixmap-root, pixmap-width, pixmap-height
>
> -LaMott
With the advent of generic functions, I don't see why we need to
prefix these accessors with their types anyway. Why not just: DEPTH,
ROOT, X, Y, WIDTH, HEIGHT, and BORDER-WIDTH? (I know X and Y aren't
very good function names, so how about LEFT and TOP with slots renamed
accordingly.) In the mean time (before generic-functions are
available), these functions can be built from typecase statements.
Warren
P.S. CLOS committee -- why all this :accessor-prefix stuff? Since
methods always do the "right thing" we need no longer resort to clever
naming schemes in order that our programs do the right thing. Surely
a concept such as HEIGHT is the same regardless of whether we're
talking about windows, fonts, displays, etc.
∂13-May-87 2117 Gregor.pa@Xerox.COM Re: CLX draft 3 revisions
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 May 87 19:49:19 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 13 MAY 87 19:48:07 PDT
Date: 13 May 87 19:47 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: CLX draft 3 revisions
In-reply-to: Warren Harris <harris%hplwhh@hplabs.HP.COM>'s message of
Wed, 13 May 87 18:55:35 PDT
To: harris%hplwhh@hplabs.HP.COM
cc: Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU,
CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
Message-ID: <870513-194807-3030@Xerox>
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
Well in fact, many people would say that surely a concept such as
'height' is NOT the same when talking about different sorts of things.
For example:
(height (make-instance 'elm-tree)) ;in FEET
(height (font-ref *default-hardcopy-font* #\a)) ;in INCHES
(height (make-instance 'window)) ;in PIXELS
They are really quite different.
Now some people are willing to overload the single generic function
height to be able to have all these different meanings.
Other consider that bad style, and would have window-height be a
generic-function which returns the height of any kind of window;
hardcopy-height be the generic-function which returns the height of
anything that can be sent to a hardcopy stream etc.
It is clear that both of these positions are reasonable. In fact, when
you want to do it one way versus another depends on lots of factors like
the size of the module you are working on. Whether the symbols in
question will be exported or imported etc.
:accessor-prefix in CLOS is designed to make it easy to program in
either of those styles.
Note that using (:accessor-prefix nil) is the way to get the behavior
you like.
∂14-May-87 0854 cperdue@Sun.COM Re: CLX draft 3 revisions
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 14 May 87 08:54:38 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
id AA09631; Thu, 14 May 87 08:51:07 PDT
Received: from clam.sun.uucp by snail.sun.com (3.2/SMI-3.2)
id AA28978; Thu, 14 May 87 08:50:41 PDT
Received: by clam.sun.uucp (3.2/SMI-3.0DEV3)
id AA12964; Thu, 14 May 87 08:55:42 PDT
Date: Thu, 14 May 87 08:55:42 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8705141555.AA12964@clam.sun.uucp>
To: Gregor.pa@Xerox.COM, harris%hplwhh@hplabs.HP.COM
Subject: Re: CLX draft 3 revisions
Cc: CL-Object-Oriented-Programming@SAIL.STANFORD.EDU,
Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
Well in fact, many people would say that surely a concept such as
'height' is NOT the same when talking about different sorts of things.
For example:
(height (make-instance 'elm-tree)) ;in FEET
(height (font-ref *default-hardcopy-font* #\a)) ;in INCHES
(height (make-instance 'window)) ;in PIXELS
Looks more like an issue of units than an issue of datatype to me.
∂14-May-87 0900 harris%hplwhh@hplabs.HP.COM Re: CLX draft 3 revisions
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 May 87 09:00:11 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Thu, 14 May 87 08:57:56 pdt
Received: from hplwhh (hplwhh) by hplms1; Thu, 14 May 87 08:57:34 pdt
Return-Path: <harris@hplwhh>
Received: from hplwhh.hpl.hp.com by hplwhh ; Thu, 14 May 87 08:57:17 pdt
Message-Id: <8705141557.AA02962@hplwhh>
To: Gregor.pa@Xerox.COM
Cc: Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU,
CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
Subject: Re: CLX draft 3 revisions
In-Reply-To: Your message of 13 May 87 19:47:00 -0700.
<870513-194807-3030@Xerox>
Date: Thu, 14 May 87 08:57:10 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
Thanks for your response. I hadn't thought about accessors like
HEIGHT differing by their units, but differing in concept (e.g. one
application's generic-function DISPLAY which takes a window and
returns its associated display object, and another application's
DISPLAY which takes an object, and a stream and draws the object). I
didn't really consider the former as requiring different accessors,
but the latter should obviously be separated by packages,
accessor-prefixes or individual names for the two operations. My gut
feeling was that prefixes shouldn't be used unless needed because they
ruin the genericness of the accessor (why should I have separate
functions for ELM-TREE-HEIGHT, PERSON-HEIGHT and FONT-HEIGHT?). But
perhaps you're right -- why confuse the user.
Warren
∂14-May-87 1054 Gregor.pa@Xerox.COM Re: CLX draft 3 revisions
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 May 87 10:54:47 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 MAY 87 10:47:15 PDT
Date: 14 May 87 10:44 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: CLX draft 3 revisions
In-reply-to: Dan Carnese <CARNESE@SPAR-20.ARPA>'s message of Thu, 14 May
87 10:21:55 PDT
To: CARNESE@SPAR-20.ARPA
cc: harris%hplwhh@hplabs.hp.com, Gregor.pa@Xerox.COM,
Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU,
CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
Message-ID: <870514-104715-3566@Xerox>
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: CLX draft 3 revisions
A basic problem with function names that include class names,
such as font-height, is that it is bad for extensibility. When
subclasses of the existing class are defined, e.g., adobe-font,
users of those subclasses will have to remember which ancestor
class must be used to construct the name of the function. This
makes such systems more difficult to learn and increases the
incidence of trivial but annoying programming errors.
Don't think of names like window-height as including the name of a
class. You should think of these as including the name of a protocol
(eg the window protocol).
Notice that the :accessor-prefix option in CLOS has no default value.
In particular, it doesn't default to the name of the class followed by a
"-". This was done to explictly avoid any automatic mapping from
class-names to accessor-prefix.
As for packages, they may sometimes be helpful for this problem. But as
I said in my earlier message, it depends on lots of things, like the
size of the module. For example, one could imagine a graphics package
which had lots of different kinds of windows and lots of different kinds
of graphics objects. Within the GRAPHICS package, it might be
appropriate to have 2 generic functions, window-height for all kinds of
windows and graphics-object-height for all kinds of graphics objects.
∂14-May-87 1031 CARNESE@SPAR-20.ARPA Re: CLX draft 3 revisions
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87 10:31:05 PDT
Date: Thu 14 May 87 10:21:55-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: CLX draft 3 revisions
To: harris%hplwhh@hplabs.hp.com
cc: Gregor.pa@XEROX.COM, Oren%Tilde%ti-csl.CSNet@RELAY.CS.NET,
RWS@ZERMATT.LCS.MIT.EDU, cl-windows@SAIL.STANFORD.EDU,
CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
In-Reply-To: <8705141557.AA02962@hplwhh>
Message-ID: <12302345450.16.CARNESE@SPAR-20.ARPA>
Date: Thu, 14 May 87 08:57:10 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
Thanks for your response. I hadn't thought about accessors like
HEIGHT differing by their units, but differing in concept (e.g. one
application's generic-function DISPLAY which takes a window and
returns its associated display object, and another application's
DISPLAY which takes an object, and a stream and draws the object). I
didn't really consider the former as requiring different accessors,
but the latter should obviously be separated by packages,
accessor-prefixes or individual names for the two operations. My gut
feeling was that prefixes shouldn't be used unless needed because they
ruin the genericness of the accessor (why should I have separate
functions for ELM-TREE-HEIGHT, PERSON-HEIGHT and FONT-HEIGHT?).
The need to distinguish is clear. The question is which language structure
is appropriate to realize the distinction.
A number of concepts, such as height and width, can be viewed as "the same"
for a number of different clx objects. Thus, it makes sense to use one
symbol to denote the concept, and thus to have one function name apply to a
number of different clx classes. By placing such symbols in the clx
package, different applications are not precluded from using symbols with
the same name, e.g., arboretum:height, to identify different concepts.
A basic problem with function names that include class names, such as
font-height, is that it is bad for extensibility. When subclasses of the
existing class are defined, e.g., adobe-font, users of those subclasses
will have to remember which ancestor class must be used to construct the
name of the function. This makes such systems more difficult to learn and
increases the incidence of trivial but annoying programming errors.
A possible reason for retaining class-specific accessor names is to achieve
maximal efficiency. If that is indeed the case, then both the "generic"
functions and the class-specific functions should be available.
-- Dan
-------
∂14-May-87 1207 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU re: geometry accessors
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 12:07:49 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 14 May 87 15:07-EDT
Date: Thu, 14 May 87 15:07 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: re: geometry accessors
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2756929653-5689439@SI>
Message-ID: <870514150711.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 13 May 87 16:47:33 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
Since you've got:
drawable-depth ...
How about getting rid of:
window-depth ...
and
pixmap-depth ...
I figured this would generate comments. At least I know people are
still reading and listening.
If you want to think of the drawable-<mumble>s as the generic functions,
that's fine. If you want to drop the "drawable-" prefix, I guess we can
argue about that. Since I think of drawables as different from other
things (like fonts), I would rather retain the prefix. So all we are
really arguing about is whether the type specializations to window and
pixmap should exist. I don't have (and haven't heard) any particularly
strong arguments either way. The specializations do serve as an
indication that the drawable- functions are the union of functionality.
That is, pixmaps don't really have x, y, and border-width, but "natural"
values have been defined.
Performance of the generic functions in non-CLOS is not a big issue
(although typecase on structure types is pretty expensive in some
implementations), since all graphics functions take drawables already.
But I haven't been convinced yet that CLOS integration with respect to
subtyping, etc. is very important either. That is, CLX objects for the
most part seem better suited as instance variables in higher-level
objects, rather than as base types.
∂14-May-87 1216 DLW@ALDERAAN.SCRC.Symbolics.COM Re: CLX draft 3 revisions
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 14 May 87 12:16:27 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 81714; Thu 14-May-87 14:29:13 EDT
Date: Thu, 14 May 87 14:28 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: CLX draft 3 revisions
To: CARNESE@SPAR-20.ARPA, harris%hplwhh@hplabs.hp.com
cc: Gregor.pa@XEROX.COM, Oren%Tilde%ti-csl.CSNet@RELAY.CS.NET, RWS@ZERMATT.LCS.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU, CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
In-Reply-To: <12302345450.16.CARNESE@SPAR-20.ARPA>
Message-ID: <870514142801.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu 14 May 87 10:21:55-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
A basic problem with function names that include class names, such as
font-height, is that it is bad for extensibility. When subclasses of the
existing class are defined, e.g., adobe-font, users of those subclasses
will have to remember which ancestor class must be used to construct the
name of the function. This makes such systems more difficult to learn and
increases the incidence of trivial but annoying programming errors.
Right. This is exactly why CLOS does not use the class name as the
accessor prefix. Instead, the writer of the defclass has to specify the
prefix, and the intention is that the prefix be specified according to
the protocol that the class implements, rather than the name of the
class.
∂14-May-87 1354 harris%hplwhh@hplabs.HP.COM Re: geometry accessors
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 May 87 13:54:36 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Thu, 14 May 87 13:53:01 pdt
Received: from hplwhh (hplwhh) by hplms1; Thu, 14 May 87 13:52:37 pdt
Return-Path: <harris@hplwhh>
Received: from hplwhh.hpl.hp.com by hplwhh ; Thu, 14 May 87 13:52:16 pdt
Message-Id: <8705142052.AA03263@hplwhh>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: geometry accessors
In-Reply-To: Your message of Thu, 14 May 87 15:07:00 -0400.
<870514150711.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 14 May 87 13:52:03 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
> But I haven't been convinced yet that CLOS integration with respect to
> subtyping, etc. is very important either. That is, CLX objects for the
> most part seem better suited as instance variables in higher-level
> objects, rather than as base types.
I see no reason why CLX objects can't be the starting point for higher
level functionality. I've spent the last few months doing just that
-- defining increasingly higher levels of window types from an
object-oriented extension to the structures provided by the C Xlib.
I've found that my primitive type, basic-window (basically the same as
a CLX window), can be specialized into windows with scroll-bars,
windows which contain graphical-object buffers, emacs-buffer-windows,
etc. I would hope that CLX is being designed with exactly this
functionality in mind -- the ability to allow its primitive data types
to be specialized. This is exactly what is missing from C Xlib, which
is why the programmer is forced to either define "higher-level
objects" which contain Xlib structs or design specific functions for
manipulating application specific window configurations. This is
hardly a reusable or efficient (in terms of programmer time) solution.
It's rare that you find an application that simply wants a window with
borders -- often times there are subwindows with special relationships
between them. Specifying and specializing these relationships is a
perfect candidate for object-oriented programming. Just take a look
at the Symbolics window system.
Warren
P.S. My window library uses :accessor-prefix nil!
∂14-May-87 1359 CARNESE@SPAR-20.ARPA Re: CLX draft 3 revisions
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87 13:59:08 PDT
Date: Thu 14 May 87 13:45:40-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: CLX draft 3 revisions
To: cl-windows@SAIL.STANFORD.EDU,
cl-object-oriented-programming@SAIL.STANFORD.EDU
In-Reply-To: <8705140155.AA02460@hplwhh>
Message-ID: <12302382544.16.CARNESE@SPAR-20.ARPA>
Date: Wed, 13 May 87 18:55:35 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
> Since you've got:
> drawable-depth, drawable-root, drawable-x, drawable-y, drawable-width,
> drawable-height, drawable-border-width
>
> How about getting rid of:
> window-depth, window-root, window-x, window-y, window-width,
> window-height, window-border-width
> and
> pixmap-depth, pixmap-root, pixmap-width, pixmap-height
>
> -LaMott
With the advent of generic functions, I don't see why we need to
prefix these accessors with their types anyway. Why not just: DEPTH,
ROOT, X, Y, WIDTH, HEIGHT, and BORDER-WIDTH? (I know X and Y aren't
very good function names, so how about LEFT and TOP with slots renamed
accordingly.) In the mean time (before generic-functions are
available), these functions can be built from typecase statements.
Warren
P.S. CLOS committee -- why all this :accessor-prefix stuff? Since
methods always do the "right thing" we need no longer resort to clever
naming schemes in order that our programs do the right thing. Surely
a concept such as HEIGHT is the same regardless of whether we're
talking about windows, fonts, displays, etc.
Two issues are raised here: how should specific pieces of clx functionality
be named and what good are accessor prefixes anyway? I was addressing the
former, not the latter. My claim was that for the above-named functions, a
single "X" in the clx package can reasonably represent the functionality of
"drawable-X", "window-X", and "pixmap-X".
As far as the appropriateness of prefixes, I think it's fair to say that
their use is a matter of personal style. Since many people do find
prefixes useful, it is entirely appropriate to have them be a language
feature. But I think it's also fair to say that if there were better
integration between the realizations of "class", "package", and "module" in
Common Lisp, the use of prefixes would be far less widespread. I'm sure
this will happen -- it just hasn't happened yet.
-------
∂14-May-87 1439 schultz@nrl-aic.ARPA Please remove...
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87 14:38:55 PDT
Return-Path: <schultz>
Received: Thu, 14 May 87 17:18:56 edt by nrl-aic.ARPA id AA22697
Date: Thu, 14 May 87 17:18:56 edt
From: Alan Schultz <schultz@nrl-aic.ARPA>
Message-Id: <8705142118.AA22697@nrl-aic.ARPA>
To: CARNESE@SPAR-20.ARPA
Cc: cl-windows@SAIL.STANFORD.EDU,
cl-object-oriented-programming@SAIL.STANFORD.EDU
In-Reply-To: Dan Carnese's message of Thu 14 May 87 13:45:40-PDT <12302382544.16.CARNESE@SPAR-20.ARPA>
Subject: Please remove...
I don't know whose responsible, but I should not be on this mailing list.
Please remove me. (Sorry for sending this to everyone, but I'm not sure
who to tell.) --Alan C. Schultz
∂18-May-87 0456 RWS@ZERMATT.LCS.MIT.EDU geometry accessors and etc.
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 May 87 04:55:10 PDT
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 51171; Mon 18-May-87 07:54:35 EDT
Date: Mon, 18 May 87 07:55 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: geometry accessors and etc.
To: cl-windows@sail.stanford.edu
Message-ID: <870518075508.9.RWS@KILLINGTON.LCS.MIT.EDU>
I'm not sure I have heard a consensus on this issue. There seem to be
those that think a prefix is desirable, and those that think it is
unnecessary (or undesirable) but apparently don't have violent
objections to it.
So, my interpretation is that the drawable-<mumble> accessors should
stay, the window-<mumble> and pixmap-<mumble> accessors should go, and
the window-<mumble> setfs should be renamed to drawable-<mumble> setfs,
but with the argument explicitly declared as window, rather than
drawable.
Is this acceptable?
Anyone want to tell me what NIL should do in the gcontext-clip-mask setf?
Have we basically reached closure on all major issues? minor issues?
BTW, a generous person has apparently made considerable progress on a
public implementation. More details as they become available.
∂18-May-87 1256 MMcM@STONY-BROOK.SCRC.Symbolics.COM Re: geometry accessors
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87 12:56:26 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 142668; Mon 18-May-87 15:50:27 EDT
Date: Mon, 18 May 87 15:49 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: geometry accessors
To: Warren Harris <harris%hplwhh@hplabs.HP.COM>
cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8705142052.AA03263@hplwhh>
Message-ID: <870518154932.3.MMCM@OWL.SCRC.Symbolics.COM>
Date: Thu, 14 May 87 13:52:03 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
I see no reason why CLX objects can't be the starting point for higher
level functionality. I've spent the last few months doing just that
-- defining increasingly higher levels of window types from an
object-oriented extension to the structures provided by the C Xlib.
I must concur with RWS on this. As I've tried to point out in earlier
messages, you mustn't confuse the X window with the higher level
application window, which I've called a window stream. The former is
just a handle for a piece of hierarchical real-estate inside the virtual
console. Its behavior is pretty much constrained by that protocol. It's
the latter whose behavior you wish to refine.
The X window is a valid piece of state of the window stream, as are the
graphics state block (GContext), TTY cursor position, mapping from
abstract character attributes to fonts, output history, and so on.
As such it makes sense being an instance variable, not the basic flavor.
If you wish to allow for situations such as a window manager running
only within the X context, then you cannot expect it to have access to
any higher level window semantics, because the window stream may not be
within its address space. If, on the other hand, you assume that the
window manager should access the window stream (perhaps only when
possible), or that a method on the window stream should be the first
agent in the sequence for client-side event processing, then you have
instituted a design philosophy which in my opinion does not belong in
this lowest layer.
Specifying and specializing these relationships is a
perfect candidate for object-oriented programming. Just take a look
at the Symbolics window system.
I should also point out that the message passing LISP machine window
system has a big pitfall. One must be crystal clear on the contract of
those messages, i.e. on the window protocol. In some cases, this is
done reasonably well; for example, there is a proper distinction between
:SET-EDGES and :CHANGE-OF-SIZE-OR-MARGINS. However, no such factoring
out has been done for :EXPOSE. This makes the interposition of
application specific behavior problematic, and quite subject to the
whims on flavor method combination. For similar reasons, I object to
the methodology in some window systems of building cursor-following
graphics by means of daemons on the fundamental graphics methods. By
doing so, you completely muddle the contract of those methods, and almost
guarantee that 50% of the graphics library routines you might want to
call won't work in your window.
I feel no particular shame in admitting any of this, as it was almost
ten years ago when a few of us designed the CADR "new" window system.
We are coming up on the time when we can learn from our experiences and
do better.
∂21-May-87 1437 harris%hplwhh@hplabs.HP.COM Re: geometry accessors
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 21 May 87 14:36:39 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Thu, 21 May 87 11:54:20 pdt
Received: from hplwhh (hplwhh) by hplms1; Thu, 21 May 87 11:53:05 pdt
Return-Path: <harris@hplwhh>
Received: from hplwhh.hpl.hp.com by hplwhh ; Thu, 21 May 87 11:50:29 pdt
Message-Id: <8705211850.AA09659@hplwhh>
To: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Warren Harris <harris%hplwhh@hplabs.HP.COM>,
Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>,
cl-windows@SAIL.STANFORD.EDU, harris%hplwhh@hplabs.HP.COM
Subject: Re: geometry accessors
In-Reply-To: Your message of Mon, 18 May 87 15:49:00 -0400.
<870518154932.3.MMCM@OWL.SCRC.Symbolics.COM>
Date: Thu, 21 May 87 11:50:23 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
It seems to me that you're making an argument against object-oriented
programming, not low-level window system protocols. The major thesis of
you message seems to state that since you can't guarantee the semantics of
a specialized method you shouldn't allow them.
Whether or not CLX is implemented in an object oriented fashion is
irrelevant to the functionality we wish to accomplish with it. However, I
see no cause for restricting the user from augmenting or modifying the
semantics of CLX via object-oriented programming if he so desires. By
permitting this we eliminate the need to define yet another low-level
protocol -- the root of the "window-stream" object hierarchy.
As far as the window manager goes, I thought it was a client just like any
other application, making requests to the server. The X server is what
exists in another address space, and has its own notion of what a window is
(defined by X11). I thought we were just trying to define a library of
routines which also made requests to this server. If the user wants to
define higher level library calls via object-oriented programming, let him.
At some level shouldn't they all filter down into well-defined requests to
the server? And if he wants to define specialized event handler methods
(like for expose-window) why shouldn't this also be permitted. Unlike the
lisp machine window system, the server is protected from unruly clients.
∂22-May-87 1333 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: geometry accessors
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87 13:33:29 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 May 87 16:25-EDT
Date: Fri, 22 May 87 16:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: geometry accessors
To: harris%hplwhh@hplabs.HP.COM, MMcM@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8705211850.AA09659@hplwhh>
Message-ID: <870522162618.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 21 May 87 11:50:23 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
It seems to me that you're making an argument against object-oriented
programming, not low-level window system protocols. The major thesis of
you message seems to state that since you can't guarantee the semantics of
a specialized method you shouldn't allow them.
I could be confused, but ...
It seems to me the disagreement is fairly simple to state. It would
seem that you believe it is OK if the "next layer up" remains X-specific
in both windowing and graphics. Others, I believe, are arguing that the
next layer up should explicitly be X-independent. It ought to work
equally well as an interface to other (existing) "window systems". X
has its own "peculiar" way of looking at the world, and it isn't
necessarily the way a programmer wants to see it. For example, the
general borders notion found in the lispm window systems might be best
achieved with nested windows in X, and it might be desirable to abstract
out the existence of these "extra" windows. Other examples relating to
graphics have previously been cited. All of these seem to be generally
characterized by the desire to take multiple X objects and make them a
single object at the next higher level, and this new object isn't
clearly an implementation-subtype of any single X object.
I suspect that more explicit expression on both sides about what the
next layer up should or shouldn't be would help a lot.
∂25-May-87 1503 MMcM@STONY-BROOK.SCRC.Symbolics.COM Re: geometry accessors
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 May 87 15:02:39 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 151212; Mon 25-May-87 17:58:29 EDT
Date: Mon, 25 May 87 17:58 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: geometry accessors
To: Warren Harris <harris%hplwhh@hplabs.HP.COM>, Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8705211850.AA09659@hplwhh>,
<870522162618.2.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870525175823.1.MMCM@OWL.SCRC.Symbolics.COM>
Date: Thu, 21 May 87 11:50:23 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
It seems to me that you're making an argument against object-oriented
programming, not low-level window system protocols. The major thesis of
you message seems to state that since you can't guarantee the semantics of
a specialized method you shouldn't allow them.
That isn't what I meant to say at all. You can indeed guarantee the
semantics of a specialized method -- and in fact it is crucially
important to the correct functioning of the window system as an
integrated whole that you do so. For this reason, it is terribly
important that you get the modular layers straight.
By
permitting this we eliminate the need to define yet another low-level
protocol -- the root of the "window-stream" object hierarchy.
I want to stress the important of defining that root of the
window-stream object hierarchy. I am afraid that failing to do so by
letting it just lie on top of CLX will cause problems down the road.
You should not eliminate the need to define the protocol.
I thought we were just trying to define a library of
routines which also made requests to this server. If the user wants to
define higher level library calls via object-oriented programming, let him.
I agree with all this. It's more or less what I was attempting to say.
The point is that the object orientation should be recognized as a
higher level library and not confused as an extension of the client
semantics which are 100% dictated by the protocol definition.
Date: Fri, 22 May 87 16:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Date: Thu, 21 May 87 11:50:23 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
It seems to me that you're making an argument against object-oriented
programming, not low-level window system protocols. The major thesis of
you message seems to state that since you can't guarantee the semantics of
a specialized method you shouldn't allow them.
I could be confused, but ...
It seems to me the disagreement is fairly simple to state. It would
seem that you believe it is OK if the "next layer up" remains X-specific
in both windowing and graphics. Others, I believe, are arguing that the
next layer up should explicitly be X-independent. It ought to work
equally well as an interface to other (existing) "window systems". X
has its own "peculiar" way of looking at the world, and it isn't
necessarily the way a programmer wants to see it. For example, the
general borders notion found in the lispm window systems might be best
achieved with nested windows in X, and it might be desirable to abstract
out the existence of these "extra" windows. Other examples relating to
graphics have previously been cited. All of these seem to be generally
characterized by the desire to take multiple X objects and make them a
single object at the next higher level, and this new object isn't
clearly an implementation-subtype of any single X object.
Yes. That is a more direct statement of one of my points. As I have
pointed out in previous messages, a higher level window stream is not
only a combination of a X window and a graphics context, it is also
often more than one X windows (in particular a subtree). Also, the
integration of streams and windowing need not preclude implementation in
low-level imagine protocols other than X11.
I suspect that more explicit expression on both sides about what the
next layer up should or shouldn't be would help a lot.
Let me try to be clear on what I am saying about object-oriented CLX. I
have no particular objection to it. It is perfectly valid programming
practice to eschew structures altogether. My point is just that you
have to be exactly as clear on the semantics of the protocols on the
next higher levels are you are on the lowest CLX levels. For this
reason, and the general desire to make the higher levels independent of
their implementation in terms of the lower, I don't see much gain by
making CLX windows be EQ to window streams.
∂25-May-87 1927 @Riverside.SCRC.Symbolics.COM,@DIAL|16177312506,@NUMBER-2.MMCM.Symbolics.COM:MMcM@NUMBER-2.MMCM.Symbolics.COM Re: geometry accessors
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 25 May 87 19:26:59 PDT
Received: from NUMBER-2.MMCM.Symbolics.COM (DIAL|16177312506) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 127841; 25 May 87 22:13:01 EDT
Date: Mon, 25 May 87 22:00 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: geometry accessors
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870522162618.2.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870525220051.5.MMCM@NUMBER-2.MMCM.Symbolics.COM>
Date: Fri, 22 May 87 16:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
I suspect that more explicit expression on both sides about what the
next layer up should or shouldn't be would help a lot.
I am sending this along separately because of the problems I know some
people have with following complex dialogues.
At the risk of boring everyone by saying exactly what I've said before
and nothing new, here is my understanding of the pieces that go into
making up the window system component of a modern LISP system.
(1) The semantic definition of the virtual console. This is exactly
what X v11 is. It defines concepts like mapped or input focus. It is
done independently of any particular language binding because of the
need (a) for different interconnection paradigms, both networked and
local and (b) for the peaceful coexistence of windows controlled by
different language modules on the same workstation.
(2) The LISP language binding of (1). This is exactly what CLX is. It
maps the abstract data structures of X into the (less abstract) data
structures of LISP. It maps the abstract control structures of X into
the control structures of LISP.
(3) The semantic definition of an integration of streams (as defined in
chapters 21 and 22 of Steele) and windows (as abstract pieces of real
estate) and objects (as defines by CLOS). This defines concepts such as
cursor position or newline height.
(4) The mapping of (3) onto (2). This is not a substitute for getting
(3) right by itself. It serves as an implementation guide. It can be
either in the form of documentation or an actual semi-portable
implementation itself.
(5 and beyond) An integration of procedural graphics, and user interface
management systems with the layers described above. I won't go into
this any further, since it will only confuse the issue.
Some notes on these points:
- I am not arguing against object-oriented programming. It is the ideal
tool for getting this job done. I cannot imagine doing it without
something like CLOS. I despair at the proposed definition of things
like X Toolkit because it can only grope at a true object orientation
within the confines of portable C. But object orientation is not an
excuse for not defining protocols clearly. It must be used as a means
toward good modularity, not a bypass around all modularity.
- I am not opposed to low-level windowing standards. I feel that most
programmers, given the choice, would program at the proper level of
abstraction, namely in terms of the higher level stream-oriented
windows. However, the existence of the higher level is not an
indictment of the lower level. The latter is essential for getting the
former right. Sometimes even an application must program in the lower
levels. When it does so, it necessarily gives up some amount of
portability by latching onto some implementation's concepts. This is
not always operating system dependence, it can also be low-level window
system dependence, as X against some other proprietary system, e.g. NewS.
- The existence of the standard LISP language binding for X v11, in the
form of CLX, does not preclude other virtual consoles within LISP.
Entirely analogously, the existence of a FORTRAN binding for GKS does
not preclude a FORTRAN binding for PHIGS. CLX says how to access an X
server from LISP, assuming a priori that you have decided that this is
the means you desire for virtual console control (for instance because
that is the only means the system you are using provides).
- The existence of a well defined window stream interface does not
preclude an application interfacing directly to the lower virtual
console layer instead. Some systems may make this more difficult than
others, by for instance having a window manager that requires an onto
mapping from X windows to window streams.
- There is a boundary at the root of the window stream protocol below
which semantics are not defined inside that layer. For instance, window
streams define how to access a character stream intended as input for a
particular window stream. They may not define how to multiplex the
shared resource of the workstation keyboard among the possible window
streams. This boundary corresponds approximately to the highest layer
of the virtual console. However, it does not limit the amount of work
that can be done by means of the lower layers directly.
- The modular separation I am proposing of CLX / window streams / UIMS
is not identical to the separation between of the C XLib / X Toolkit.
One thing that should be kept in mind is that it is not necessary to
agree on the complete semantics of any layer to recognize what layer a
particular functionality belongs in. For example, I would put a
function for choosing from a pop-up/pull-down menu in the UIMS category.
However, I am quite sure that we could agree on a function name and
calling sequence for it long before much of anything else in that
category. We should not be compelled to misplace it into the window
stream layer just because we want to agree on it earlier on.
- Using separate objects to represent data objects within the virtual
console from window streams makes the modular separation crystal clear.
Defining a protocol for the simplest window stream involves no
duplication of effort, because where one protocol leaves off the other
takes up.
- I do not see an unambiguous identity between any single pair of
objects in the two layers.
- I find the need for the object system compelling for any
implementation of window streams. I do not find such compelling need
for the case of CLX itself, because the semantics are so well restricted
by the protocol definition.
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: geometry accessors
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870522162618.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Fri, 22 May 87 16:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
I suspect that more explicit expression on both sides about what the
next layer up should or shouldn't be would help a lot.
I am sending this along separately because of the problems I know some
people have with following complex dialogues.
At the risk of boring everyone by saying exactly what I've said before
and nothing new, here is my understanding of the pieces that go into
making up the window system component of a modern LISP system.
(1) The semantic definition of the virtual console. This is exactly
what X v11 is. It defines concepts like mapped or input focus. It is
done independently of any particular language binding because of the
need (a) for different interconnection paradigms, both networked and
local and (b) for the peaceful coexistence of windows controlled by
different language modules on the same workstation.
(2) The LISP language binding of (1). This is exactly what CLX is. It
maps the abstract data structures of X into the (less abstract) data
structures of LISP. It maps the abstract control structures of X into
the control structures of LISP.
(3) The semantic definition of an integration of streams (as defined in
chapters 21 and 22 of Steele) and windows (as abstract pieces of real
estate) and objects (as defines by CLOS). This defines concepts such as
cursor position or newline height.
(4) The mapping of (3) onto (2). This is not a substitute for getting
(3) right by itself. It serves as an implementation guide. It can be
either in the form of documentation or an actual semi-portable
implementation itself.
(5 and beyond) An integration of procedural graphics, and user interface
management systems with the layers described above. I won't go into
this any further, since it will only confuse the issue.
Some notes on these points:
- I am not arguing against object-oriented programming. It is the ideal
tool for getting this job done. I cannot imagine doing it without
something like CLOS. I despair at the proposed definition of things
like X Toolkit because it can only grope at a true object orientation
within the confines of portable C. But object orientation is not an
excuse for not defining protocols clearly. It must be used as a means
toward good modularity, not a bypass around all modularity.
- I am not opposed to low-level windowing standards. I feel that most
programmers, given the choice, would program at the proper level of
abstraction, namely in terms of the higher level stream-oriented
windows. However, the existence of the higher level is not an
indictment of the lower level. The latter is essential for getting the
former right. Sometimes even an application must program in the lower
levels. When it does so, it necessarily gives up some amount of
portability by latching onto some implementation's concepts. This is
not always operating system dependence, it can also be low-level window
system dependence, as X against some other proprietary system, e.g. NewS.
- The existence of the standard LISP language binding for X v11, in the
form of CLX, does not preclude other virtual consoles within LISP.
Entirely analogously, the existence of a FORTRAN binding for GKS does
not preclude a FORTRAN binding for PHIGS. CLX says how to access an X
server from LISP, assuming a priori that you have decided that this is
the means you desire for virtual console control (for instance because
that is the only means the system you are using provides).
- The existence of a well defined window stream interface does not
preclude an application interfacing directly to the lower virtual
console layer instead. Some systems may make this more difficult than
others, by for instance having a window manager that requires an onto
mapping from X windows to window streams.
- There is a boundary at the root of the window stream protocol below
which semantics are not defined inside that layer. For instance, window
streams define how to access a character stream intended as input for a
particular window stream. They may not define how to multiplex the
shared resource of the workstation keyboard among the possible window
streams. This boundary corresponds approximately to the highest layer
of the virtual console. However, it does not limit the amount of work
that can be done by means of the lower layers directly.
- The modular separation I am proposing of CLX / window streams / UIMS
is not identical to the separation between of the C XLib / X Toolkit.
One thing that should be kept in mind is that it is not necessary to
agree on the complete semantics of any layer to recognize what layer a
particular functionality belongs in. For example, I would put a
function for choosing from a pop-up/pull-down menu in the UIMS category.
However, I am quite sure that we could agree on a function name and
calling sequence for it long before much of anything else in that
category. We should not be compelled to misplace it into the window
stream layer just because we want to agree on it earlier on.
- Using separate objects to represent data objects within the virtual
console from window streams makes the modular separation crystal clear.
Defining a protocol for the simplest window stream involves no
duplication of effort, because where one protocol leaves off the other
takes up.
- I do not see an unambiguous identity between any single pair of
objects in the two layers.
- I find the need for the object system compelling for any
implementation of window streams. I do not find such compelling need
for the case of CLX itself, because the semantics are so well restricted
by the protocol definition.
∂02-Jun-87 1238 @RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET font-char-info
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 2 Jun 87 12:38:38 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac14189; 2 Jun 87 12:48 EDT
Received: from ti-csl by RELAY.CS.NET id ac24086; 2 Jun 87 12:46 EDT
Received: by tilde id AA00347; Tue, 2 Jun 87 10:44:42 CDT
Message-Id: <2758635907-4127499@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 2 Jun 87 10:45:07 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: cl-windows@SAIL.STANFORD.EDU
Subject: font-char-info
FONT-CHAR-INFO is defined to return a CHAR-INFO structure. If font
char-info's are stored as a vector of unnamed structures, it will take 5
words per character. If char-info's are stored packed in an array, only
3 words per character are used, but 5 words would have to be consed up
by FONT-CHAR-INFO to return the data, and FONT-CHAR-INFOS gets really
ugly. How about adding a font parameter to the "char-" accessors:
(DEFUN char-width (font char &optional second-byte)
(declare (type font font)
(type (or integer character (member :min :max)) char)
(type (or integer character) second-byte) ;; for 16 bit fonts
(values integer)))
(DEFUN char-ascent (font char &optional second-byte) ...)
(DEFUN char-descent (font char &optional second-byte) ...)
(DEFUN char-left-bearing (font char &optional second-byte) ...)
(DEFUN char-right-bearing (font char &optional second-byte) ...)
(DEFUN char-attributes (font char &optional second-byte) ...)
Note that these will take a character type, where the original CLX
functions only took integers. We could get rid of font-char-info,
font-char-infos, font-char16-info, font-min-bounds font-max-bounds,
font-info-min-bounds and font-info-max-bounds.
Also, how about getting rid of the font-info structure, and
font-font-info. This seems like a useless abstraction, since
there are font-<name> accessors for all the font-info fields.
LaMott
∂03-Jun-87 0126 @RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET Re: [LaMott Oren <Oren@Tilde.ti>: font-char-info]
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 3 Jun 87 01:26:53 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aj24084; 3 Jun 87 4:22 EDT
Received: from ti-csl by RELAY.CS.NET id ah28693; 3 Jun 87 4:17 EDT
Received: by tilde id AA09550; Tue, 2 Jun 87 15:00:58 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 2 Jun 87 15:03:55 CDT
Message-Id: <2758651286-3361190@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 2 Jun 87 15:01:26 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: [LaMott Oren <Oren@Tilde.ti>: font-char-info]
In-Reply-To: Msg of Tue, 2 Jun 87 10:49:34 CDT from LaMott Oren <Oren@Tilde.ti>
Good thinn'n, Baba Louie! Agreed on each of your suggestions (font parameter for
char- accessors, use of character type parameters, consolidation of 8- and
16-bit char set accessors, and elimination of font-info defstruct.)
∂03-Jun-87 0729 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU font-char-info
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 07:06:20 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 3 Jun 87 10:05-EDT
Date: Wed, 3 Jun 87 10:05 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: font-char-info
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2758635907-4127499@SI>
Message-ID: <870603100518.3.RWS@KILLINGTON.LCS.MIT.EDU>
FONT-CHAR-INFO is defined to return a CHAR-INFO structure.
Just to be clear, it isn't required to be a structure (in the sense of
defstruct), just an object with accessor-like functions.
If font
char-info's are stored as a vector of unnamed structures, it will take 5
words per character.
In a system supporting 32-bit fixnums, if the font-char-infos array were
abstracted to something with an aref-like function, then char-infos
could be stored as a (cdr-coded) list, 3 words per char-info, and a
char-info could just be the appropriate nthcdr of the list.
Alternatively, the CLX implementation could assign a unique index
(across all open displays) to each active font, and a char-info could be
a fixnum encoding the font index and the index into the packed array of
char-info metrics.
(DEFUN char-width (font char &optional second-byte)
(declare (type font font)
(type (or integer character (member :min :max)) char)
(type (or integer character) second-byte) ;; for 16 bit fonts
(values integer)))
Do you really want character, or just string-char?
Making second-byte optional is either confusing or "wrong". For a
matrix (e.g., Japanese) font, it can still be useful to elide one index
when it is zero, but the normal one to elide is first-byte, not
second-byte. That is, Latin-1 is normally embedded in a matrix font
with first-byte = zero. This either means that your definition doesn't
usefully support such one-byte indexing on a matrix font, or else the
required arg changes interpretation between first-byte and second-byte,
depending on whether the optional arg is present.
Another problem, which I now notice is also true of the existing CLX
interface, is that the X protocol allows you to query font information
given a gcontext, without knowledge of the embedded font id. There
needs to be an interface to this mechanism. Allowing a gcontext in your
function above will get us into caching and cache-invalidation problems.
In the existing proposal, one can simply add a function
(defun gcontext-font-info (gcontext)
(declare (type gcontext gcontext)
(values font-info (array char-info))))
Also, how about getting rid of the font-info structure, and
font-font-info. This seems like a useless abstraction, since
there are font-<name> accessors for all the font-info fields.
The font-info structure is necessary because of list-fonts-with-info,
and also because of the need to query font-info via a gcontext.
I'm not completely against getting rid of char-info as an object, but I
don't think the right alternative has been hit upon yet. Rather than
abstracting char-info accessors into the font object, perhaps it would
be better to abstract the array of char-infos into a char-metrics object
and place the accessors on that. We would still have to argue about
whether (or integer character) and an optional arg were preferable to
multiple accessors. The min-bounds and max-bounds in a font-info would
still have to be provided, I guess as 12 font-info accessors. One could
instead try to fold min/max into the char-metrics, but
list-fonts-with-info only returns min/max, not the other metrics,
although I suppose one could make sense of a char-metrics object that
contained min/max information but was otherwise zero length.
(defun char-width (char-metrics char)
(declare (type char-metrics char-metric)
(type integer char) ; (or integer string-char)?
(values integer)))
(defun char16-width (char-metrics first-byte second-byte)
(declare (type char-metrics char-metric)
(type integer first-byte second-byte)
(values integer)))
(defun font-font-info (font)
(declare (type font font)
(values font-info)))
(defun font-char-metrics (font)
(declare (type font font)
(values char-metrics)))
(defun gcontext-font-info (gcontext)
(declare (type gcontext gcontext)
(values font-info char-metrics)))
(defun font-info-min-width (font-info)
(declare (type font-info font-info)
(values integer)))
(defun font-info-max-width (font-info)
(declare (type font-info font-info)
(values integer)))
or perhaps?
(defun font-info-char-width (font-info &optional min-p)
or perhaps?
(defun char-bounding-width (char-metrics &optional min-p)
(declare (type char-metrics char-metrics)
(values integer)))
∂03-Jun-87 1215 @RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET Re: font-char-info
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 3 Jun 87 12:13:08 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac00400; 3 Jun 87 15:06 EDT
Received: from ti-csl by RELAY.CS.NET id ad01795; 3 Jun 87 15:02 EDT
Received: by tilde id AA04688; Wed, 3 Jun 87 12:29:05 CDT
Message-Id: <2758728555-9693923@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 3 Jun 87 12:29:15 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: font-char-info
In-Reply-To: Msg of Wed, 3 Jun 87 10:05 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Since the only way you can get char-metrics (or char-info) is from a
font, why not pass in a font instead, eliminating the char-metrics
object? Instead of 6 more functions, why not an optional argument?
How about:
(DEFUN char-width (font char &optional (first-byte 0))
;; FIRST-BYTE is ignored for 8 bit fonts
(declare (type font font)
(type (or integer string-char) char)
(type integer first-byte)
(values integer)))
I can't imagine anyone needing the min without needing the max also, so
how about:
(defun font-width (font)
(declare (type (or font font-info gcontext) font)
(values max min)))
> Another problem, which I now notice is also true of the existing CLX
> interface, is that the X protocol allows you to query font information
> given a gcontext, without knowledge of the embedded font id. There
> needs to be an interface to this mechanism. Allowing a gcontext in your
> function above will get us into caching and cache-invalidation problems.
It seems to me that the "caching and cache-invalidation problems" are
easy to solve. When the font for a gcontext isn't known, a font object
with a null font-id and name (with valid font-info) can be put in the
gcontext cache. For safety, a hack could be put into gcontext-font to
return NIL when the cached font doesn't have a font-id. Isn't this
caching required for text-extents anyway?
I was hoping to simplify the font structures. It seems really messy to
have to deal with 3 kinds of structures (font font-info and char-metrics
or char-info) to get information about a single abstraction. Since
list-fonts-with-info is the only thing that exposes the font-info
structure, how about letting it return a sequence of font structures
(with null font-id's), and extending open-font to let name be a
fontable.
If you're worried about efficency, I was assuming that text-extents
would use an internal char-metrics structure directly rather using
char-width and friends. It seems to me that char-width (& friends)
won't be used much, and they should be simple to use.
- LaMott
∂03-Jun-87 1316 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: font-char-info
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 13:15:50 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 3 Jun 87 15:58-EDT
Date: Wed, 3 Jun 87 15:58 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: font-char-info
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2758728555-9693923@SI>
Message-ID: <870603155820.2.RWS@KILLINGTON.LCS.MIT.EDU>
Since the only way you can get char-metrics (or char-info) is from a
font, why not pass in a font instead, eliminating the char-metrics
object?
Because you can get them "from a font" without actually having the
font object/id in your hand, by indirecting through a gcontext.
(DEFUN char-width (font char &optional (first-byte 0))
;; FIRST-BYTE is ignored for 8 bit fonts
(declare (type font font)
(type (or integer string-char) char)
(type integer first-byte)
(values integer)))
The only thing bad about this is that the arguments are backwards.
One would expect "first-byte" to come "first", that's all.
I can't imagine anyone needing the min without needing the max also, so
how about:
(defun font-width (font)
(declare (type (or font font-info gcontext) font)
(values max min)))
Max is useful without min. Dunno about min alone. Given that in most
other places we've worked hard to eliminate MVs, doesn't seem right to
put them in here.
When the font for a gcontext isn't known, a font object
with a null font-id and name (with valid font-info) can be put in the
gcontext cache. For safety, a hack could be put into gcontext-font to
return NIL when the cached font doesn't have a font-id.
If you create "funny" font objects, then you have to check for them
everywhere fonts are used. One shouldn't be able to pass such a font to
draw-text. I suppose one could use generic functions to get around this
(except when don't want to require that) or hack around it by declaring
things as "(or font funny-font)" versus "font", but it doesn't taste
quite right to me.
Isn't this
caching required for text-extents anyway?
No. If the font in the gcontext isn't known, you fall back on the
QueryExtents protocol request, which accepts a gcontext.
I was hoping to simplify the font structures. It seems really messy to
have to deal with 3 kinds of structures (font font-info and char-metrics
or char-info) to get information about a single abstraction.
Note that I proposed flushing char-info, and perhaps even merging
char-metrics into font-info. I'm just not convinced font-info should be
the same thing as font. I guess I don't consider a "funny font" as any
cleaner than an extra abstraction or two.
Since
list-fonts-with-info is the only thing that exposes the font-info
structure, how about letting it return a sequence of font structures
(with null font-id's), and extending open-font to let name be a
fontable.
This just seems like a hack.
If you're worried about efficency, I was assuming that text-extents
would use an internal char-metrics structure directly rather using
char-width and friends.
Like you (I think), I'm more worried about representation efficiency
than access, but I also don't want a hack interface.
It seems to me that char-width (& friends)
won't be used much, and they should be simple to use.
If they aren't used much, simplicity doesn't matter. However, I think
it's too early to tell whether text-width and text-extents will be the
canonical use.
∂03-Jun-87 1550 @RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET Re: font-char-info
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 3 Jun 87 15:50:42 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02448; 3 Jun 87 18:41 EDT
Received: from ti-csl by RELAY.CS.NET id aj02907; 3 Jun 87 18:33 EDT
Received: by tilde id AA12228; Wed, 3 Jun 87 17:02:58 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 3 Jun 87 17:06:47 CDT
Message-Id: <2758744970-8989885@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 3 Jun 87 17:02:50 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: font-char-info
In-Reply-To: Msg of Wed, 3 Jun 87 10:05 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Regarding the following proposed accessor(s):
(DEFUN char-width (font char &optional second-byte)
(declare (type font font)
(type (or integer character (member :min :max)) char)
(type (or integer character) second-byte) ;; for 16 bit fonts
(values integer)))
You're right -- the string-char data type should be used instead of character.
>For a
>matrix (e.g., Japanese) font, it can still be useful to elide one index
>when it is zero, but the normal one to elide is first-byte, not
>second-byte. That is, Latin-1 is normally embedded in a matrix font
>with first-byte = zero. This either means that your definition doesn't
>usefully support such one-byte indexing on a matrix font, or else the
>required arg changes interpretation between first-byte and second-byte,
>depending on whether the optional arg is present.
Good point, although the current CLX doesn't support such ellipsis at all. Here,
at least, we have a chance, and with the proper interpretation of "first", we
can allow the ellipsis without confusion. Something like:
(DEFUN char-width (font least-significant-byte
&optional most-significant-byte))
>The font-info structure is necessary because of list-fonts-with-info
Hmm, you're right again.
Well, it took me some head scratching to get through all of this, but I now
think I see some of these questions in terms of the familiar trade-off between
interface smoothness and implementation complexity. On the one hand, it seems
that char-info (or char-metrics) could be eliminated as distinct object types.
After all, the char-info's are functionally dependent on the font (or gcontext)
object. It seems natural to think of char metric stuff (e.g. char-width) as a
function of two variables , rather than as a composition of two functions (e.g.
(char-width (font-char-metrics font) char)). On the other hand, (char-width
gcontext font) seems to require one of the following alternatives:
1. Char-info's for the gcontext are queried, used, then thrown away.
This looks like an intolerable performance problem.
2. A cache associating char-info's with gcontext must be maintained,
apart from but synchronized with the (optional) gcontext cache. This
looks a little twisty.
Dunno what's best.
∂04-Jun-87 1530 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: font-char-info
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jun 87 15:30:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 164249; Thu 4-Jun-87 18:27:48 EDT
Date: Thu, 4 Jun 87 18:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: font-char-info
To: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>, LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>,
Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2758744970-8989885@Sierra>
Message-ID: <870604182740.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 3 Jun 87 17:02:50 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
Regarding the following proposed accessor(s):
(DEFUN char-width (font char &optional second-byte)
(declare (type font font)
(type (or integer character (member :min :max)) char)
(type (or integer character) second-byte) ;; for 16 bit fonts
(values integer)))
You're right -- the string-char data type should be used instead of character.
I disagree. It would be a serious mistake to allow either character or
string-char here. The whole concept of "character" at the CLX level is
different from the Common Lisp concept of "character", and they should not
be confused. What X and CLX call a "character" is an index into a specific
font, selecting a specific pattern to be drawn on the screen, and has no
meaning without the context of that font. What Common Lisp calls a
"character" is at a much higher level of modularity and has meaning in the
absence of any font or window context.
When the Common Lisp WRITE-STRING function is called, with its second
argument a stream that connects to an X window, there must be a translation
from the Common Lisp characters in the string to the X font(s) and indices
into those fonts. We know from the way CLX is defined that this
translation happens in the caller of CLX, not inside CLX. It's only a
coincidence if in some simple cases the translation from Common Lisp
character object to X character number happens to be the Common Lisp
function CHAR-CODE; in general the translation will be more complex, and no
particular translation can be built into CLX. This becomes especially
clear when you realize that in general the translation is to both a
character number and a font, not to just a character number; therefore
anything that takes a font as an argument cannot be the right level of
modularity to perform the translation.
(DEFUN char-width (font least-significant-byte
&optional most-significant-byte))
I sure can't understand why everyone thinks these functions have to
receive two bytes as separate arguments when the character number is
larger than 255. Why not make the arguments be a font and a character
number, and leave it to the CLX implementation to figure out how to
encode the character number as bytes for transmission?
I don't have anything to add to the main part of the discussion, about
the issues derived from the fact that the X protocol allows separate
access to the font metrics and the font bit-patterns.
∂04-Jun-87 2132 RWK@YUKON.SCRC.Symbolics.COM Re: font-char-info
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jun 87 21:31:49 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219256; Fri 5-Jun-87 00:05:47 EDT
Date: Fri, 5 Jun 87 00:05 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: font-char-info
To: cl-windows@SAIL.STANFORD.EDU
cc: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>,
LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>, Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
In-Reply-To: <870604182740.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870605000536.1.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
I agree with everything Moon said about CLX dealing in fonts and
indexes into those fonts, and not characters or string-chars. It
seems that the range of these indexes should be determined by the
size of the font, and not by 8 bits.
However, before CLX can be useful, we need interfaces at a higher
level that translate from characters (including the CHAR-FONT field
if any) into fonts and indexes. As MMcM points out, we can define
a few things at another layer of abstraction, without having to
agree on that entire higher layer.
For example:
(defun char-font-and-index (character stream)
(declare (type string-char character)
(type display-stream stream))
(values font index))
where a DISPLAY-STREAM is something which may convey both knowledge
about the mapping between the local idea of characters and the
foreign fonts, and perhaps some dynamic state in systems which have
concepts like "current font". I'm not certain it wants to be a stream.
If we're ambitious, we could also define functions DRAW-CHAR and
DRAW-STRING. These would call CHAR-FONT-AND-INDEX, and call the
appropriate 8-bit or 16-bit drawing functions from the CLX level,
as needed.
My point is that, while Moon's comments are 100% on the mark, that
it doesn't mean you're left with something useless or even awkward.
It's just a necessary building-block to build the tools we REALLY
want.
∂05-Jun-87 0527 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: font-char-info
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 05:27:18 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 Jun 87 08:26-EDT
Date: Fri, 5 Jun 87 08:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: font-char-info
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2758744970-8989885@Sierra>
Message-ID: <870605082624.2.RWS@KILLINGTON.LCS.MIT.EDU>
>For a
>matrix (e.g., Japanese) font, it can still be useful to elide one index
>when it is zero, but the normal one to elide is first-byte, not
>second-byte. That is, Latin-1 is normally embedded in a matrix font
>with first-byte = zero. This either means that your definition doesn't
>usefully support such one-byte indexing on a matrix font, or else the
>required arg changes interpretation between first-byte and second-byte,
>depending on whether the optional arg is present.
Good point, although the current CLX doesn't support such ellipsis at all. Here,
at least, we have a chance, and with the proper interpretation of "first", we
can allow the ellipsis without confusion. Something like:
(DEFUN char-width (font least-significant-byte
&optional most-significant-byte))
I don't want to harp on this too much, but I doubt the "without
confusion". The Japanese we've talked with are quite adamant about the
way they think. Either you ignore them (which is unwise), or you
provide an interface that matches the way they think (it is unlikely you
can change the way they think on this issue). They don't think in terms
of "least significant" and "most significant". They don't think in
terms of 16-bit values. They very definitely think in terms of "first
byte" and "second byte". The protocol is (re)designed around this way
of thinking, except in a very few cases where it was felt to not matter
(the default-char in a font, the glyph indexes in CreateGlyphCursor).
Even so, we get complaints that things are named PolyText"16" instead of
PolyText"2B".
Naming the arguments as you suggest won't eliminate confusion. Naming
them "second-byte" and "first-byte" will, but having them in the "wrong"
order seems likely to cause confusion. I suggest that separate
(one-byte versus two-byte) accessors are the only good solution.
∂05-Jun-87 0904 FAHLMAN@C.CS.CMU.EDU font-char-info
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 09:04:30 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 5 Jun 87 12:03:56-EDT
Date: Fri, 5 Jun 1987 12:03 EDT
Message-ID: <FAHLMAN.12308098410.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: font-char-info
In-reply-to: Msg of 5 Jun 1987 08:26-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
The Japanese we've talked with are quite adamant about the
way they think. Either you ignore them (which is unwise), or you
provide an interface that matches the way they think (it is unlikely you
can change the way they think on this issue). They don't think in terms
of "least significant" and "most significant". They don't think in
terms of 16-bit values. They very definitely think in terms of "first
byte" and "second byte". The protocol is (re)designed around this way
of thinking, except in a very few cases where it was felt to not matter
(the default-char in a font, the glyph indexes in CreateGlyphCursor).
Even so, we get complaints that things are named PolyText"16" instead of
PolyText"2B".
Is Kanji the only likely client for a font that has more than 256
characters? I believe that there are some other alphabets that fall
into this category and also some made-up symbol systems that might want
to be dealt with as fonts and character strings. It seems to me that
the principal abstraction CLX should provide is a font of arbitrary
size, indexed by an integer whose legal range is a function of that
font.
It is a trivial matter (best handled at the next level up?) to provide a
translation function from the "natural" representation for any given
alphabet into the single-integer value to be used with a certain font.
For Japanese, this is presumably (+ (* 256 first-byte) second-byte).
For an "alchemy symbols" alphabet, it might be something rather
different.
I won't object if CLX actually provides the Japanese interface as a
generally-useful utility, but I don't think we should let their
particular way of thinking about characters control the design of the
basic interface to fonts, any more than we should dictate that all fonts
must correspond directly to ASCII.
-- Scott
∂05-Jun-87 1142 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: font-char-info
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 11:42:12 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 Jun 87 14:40-EDT
Date: Fri, 5 Jun 87 14:40 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: font-char-info
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870604182740.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870605144033.0.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 4 Jun 87 18:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
It would be a serious mistake to allow either character or
string-char here. The whole concept of "character" at the CLX level is
different from the Common Lisp concept of "character", and they should not
be confused.
I agree in principle, but I'm not sure I agree in practice. Note that
the CLX draw functions (e.g., draw-string) take strings as arguments.
My intention was that the CHAR-CODEs be used, not that CLX do
translation. If draw-string uses string-chars, it isn't clear to me why
metric accessors shouldn't as well (although I happen to not
particularly care in the accessor case). You might argue that
draw-string ought to be renamed and ought to take an array of integers,
and I might agree that such a function should also exist, but strings
seem like they will be a very common medium of exchange, and you don't
want to introduce transformation inefficiencies unless you absolutely
have to. One can perhaps argue that the fonts are likely to be chosen
so that their glyph indexing matches CHAR-CODE, or that in the majority
of cases CHAR-CODE will tend to match ASCII. None of this is absolute,
of course, but neither are they that unlikely.
(DEFUN char-width (font least-significant-byte
&optional most-significant-byte))
I sure can't understand why everyone thinks these functions have to
receive two bytes as separate arguments when the character number is
larger than 255. Why not make the arguments be a font and a character
number, and leave it to the CLX implementation to figure out how to
encode the character number as bytes for transmission?
Perhaps my (by now previous) mail will have explained it. I, too, took
a "what difference does it make?" attitude about this in the initial
protocol specification, thinking it could be plastered over by the
language interfaces. The fact remains that many Japanese don't see it
this way. I have trouble clearly explaining why, and I feel
uncomfortable trying to argue their position, and the more I say the
bigger foot I'm likely to stick in my mouth.
∂05-Jun-87 1206 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU font-char-info
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 12:05:52 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 Jun 87 15:04-EDT
Date: Fri, 5 Jun 87 15:04 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: font-char-info
To: Fahlman@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308098410.BABYL@C.CS.CMU.EDU>
Message-ID: <870605150425.1.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Fri, 5 Jun 1987 12:03 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Is Kanji the only likely client for a font that has more than 256
characters? I believe that there are some other alphabets that fall
into this category and also some made-up symbol systems that might want
to be dealt with as fonts and character strings.
I certainly don't claim to be an expert in this area, but there
definitely are other large-alphabet languages, and the matrix encoding
with "first-byte/second-byte" semantics is (through ISO) pretty much
standard. General "large fonts" in this country are (I think) not so
common right now, but some people I have talked to think they will be
soon. However, for them, I don't see any clear cut about linear versus
matrix encoding (which is one reason why X provides support for both in
the >256 case).
It is a trivial matter (best handled at the next level up?) to provide a
translation function from the "natural" representation for any given
alphabet into the single-integer value to be used with a certain font.
Well, this gets back to representation in compound objects as well. The
Japanese want their "draw-kanji-string" function to take a string of
bytes (of even length), and interpret them in order as first/second
bytes. You don't want to convert pairs into singletons, have them
possibly byte-swapped, and then converted back to pairs, you want
interfaces all the way through to treat them the same.
I won't object if CLX actually provides the Japanese interface as a
generally-useful utility, but I don't think we should let their
particular way of thinking about characters control the design of the
basic interface to fonts, any more than we should dictate that all fonts
must correspond directly to ASCII.
The fact that you view a font as linear (indexed in whatever manner by
"an integer") is a bias. This seems pretty much a Lilliputian argument
versus a Blefuscuian one; I don't see that our culture is "right" just
because it can be show to achieve the opposite "end".
∂05-Jun-87 1946 RWK@YUKON.SCRC.Symbolics.COM Not about font-char-info
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jun 87 19:46:12 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219835; Fri 5-Jun-87 21:53:10 EDT
Date: Fri, 5 Jun 87 21:52 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Not about font-char-info
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: Fahlman@C.CS.CMU.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870605150425.1.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870605215252.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Fri, 5 Jun 87 15:04 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
The fact that you view a font as linear (indexed in whatever manner by
"an integer") is a bias. This seems pretty much a Lilliputian argument
versus a Blefuscuian one; I don't see that our culture is "right" just
because it can be show to achieve the opposite "end".
I disagree. It's a matter of modularity. Concepts and objects
being passed around should be one-to-one. If you want to package
the low-byte and high-byte into a "matrix-font-address" object,
then I'll agree; it's just my biases that say I'd rather just have
an integer and a flat font.
This first-byte second-byte stuff is all about encoding JIS Kanji
characters into 7-bit and 8-bit byte files and data streams. I don't
read Kanji, but I haven't seen anything to suggest it says you have to
use 8-bit bytes in your programs.
The Japanese problem is one of letting the underlying communications
protocol leak out into the higher layers. But I must admit they have
cause. If you had to think about 6802 characters, (yes, that's the
number for JIS Kanji Level 2) you'd find it easier to find them in a 2-D
table. In almost everything you do, you have to deal with the encoding,
because most systems they are using have a string 8-bit bias. (Not to
mention PDP-10 & -20's with their 7-bit bias). Just to look up the
codes in a table, you'd have to split them out into the two bytes,
since all the tables of characters are organized that way.
So I have sympathy, but I still think it's the wrong approach. If you
think about CLX as a layer between CL, where you deal with characters,
not bytes, and X, where you're dealing with bytes on the net, you have
to ask yourself, "self, where do these bytes come from?" And where do
you use them? The answer is that you asked the same agent that got you
the font, and the only thing you can do with them is give them to the
network connection that agent was describing. If you go and put them in
a file, they could have another meaning. Perhaps *this* font was really
not Kanji at all, but Sumerian or something.
But that said, I can see a great deal of convenience to be had for a
person used to working with the JIS/ISO encoding schemes for Kanji
to see the two byte values while developing and debugging his system
built on CLX. For example, he may be comparing it with what his non-Lisp
tools tell him was in the file. (I've been fortunate enough to never
have to use Kanji on a non-Lisp system, so our use of a 6802-long font
has never seemed the problem; it was the JIS/ISO representation that
has seemed the problem. Your Gulliver's Travels scenario at work here.)
My recommendation is to adopt flat fonts AS THE MODEL. That is, the
standard interfaces all treat all fonts as flat. However, provide
a set of ALTERNATE interfaces which use the same fonts in the
first-byte second-byte model. Document this second interface as being
for the convenience of humans who have been raised on the JIS/ISO model.
(Note that the ISO standard does not apply here at all, this is just
to make life easier). Document that it adds no additional functionality
and can be written trivially in terms of the other interface. Don't
mandate the use of one or the other in any particular situation.
∂05-Jun-87 1947 RWK@YUKON.SCRC.Symbolics.COM Re: font-char-info
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jun 87 19:47:08 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219837; Fri 5-Jun-87 22:00:26 EDT
Date: Fri, 5 Jun 87 22:00 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: font-char-info
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870605144033.0.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870605220016.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Fri, 5 Jun 87 14:40 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Date: Thu, 4 Jun 87 18:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
It would be a serious mistake to allow either character or
string-char here. The whole concept of "character" at the CLX level is
different from the Common Lisp concept of "character", and they should not
be confused.
I agree in principle, but I'm not sure I agree in practice. Note that
the CLX draw functions (e.g., draw-string) take strings as arguments.
My intention was that the CHAR-CODEs be used,
This is clearly wrong. CHAR-CODES don't have anything to do
with indexes in fonts. Nowhere in CLtL does it even suggest
they might.
not that CLX do
translation. If draw-string uses string-chars, it isn't clear to me why
metric accessors shouldn't as well (although I happen to not
particularly care in the accessor case). You might argue that
draw-string ought to be renamed and ought to take an array of integers,
and I might agree that such a function should also exist, but strings
seem like they will be a very common medium of exchange, and you don't
want to introduce transformation inefficiencies unless you absolutely
have to. One can perhaps argue that the fonts are likely to be chosen
so that their glyph indexing matches CHAR-CODE, or that in the majority
of cases CHAR-CODE will tend to match ASCII. None of this is absolute,
of course, but neither are they that unlikely.
I don't think you can scale this argument up to multiple character-sets
implemented with separate, distinct fonts for each character-set. The
CL idea of "font" cannot be used to implement separate character-sets
without introducing lots of bugs due to CL's specification for comparison
operations and so on ignoring the CHAR-FONT field. Thus you would have
an equivalence between a kanji character and a Greek letter and the letter
A. Clearly not right. The character-set has to be encoded into the
CHAR-CODE. But if CHAR-CODE is the mapping from the character to the
index, that means ALL character-sets must live in a single font! Hardly
a reasonable requirement. So yes, I would say it is highly unlikely that
CHAR-CODE will match the glyph index.
∂08-Jun-87 1637 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU wither characters
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87 16:36:53 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 Jun 87 19:36-EDT
Date: Mon, 8 Jun 87 19:36 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: wither characters
To: cl-windows@sail.stanford.edu
Message-ID: <870608193615.9.RWS@KILLINGTON.LCS.MIT.EDU>
Let's see if I can summarize a bit:
The idea of using or depending on characters at the CLX level is less
than desirable to many people, for both semantic reasons and for
portability (CL doesn't require a 16-bit char-code-limit). It is more
desirable to stick strictly to an integer interface, and leave character
translation to the next higher level.
Besides the metric accessors, this affects
text-extents
text-width
draw-string
draw-text
draw-image-string
and their 16-bit/2-byte relatives:
text16-extents
text16-width
draw-string16
draw-text16
draw-image-string16
There is disagreement about whether the integer interface should expose
the matrix encoding (even if only optionally). I might be convinced
about hiding two-byteness at the character level; I'm less sure there
are compelling arguments at this "rawer" integer level, except that it
seems to simplify the interface (viz., the "16" functions don't need a
bytes-p argument).
I guess I'm tentatively willing to go this direction (integer only, with
matrix hidden). Are there any dissenters?
∂08-Jun-87 1724 RAM@C.CS.CMU.EDU wither characters
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87 17:23:50 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 8 Jun 87 20:23:11-EDT
Date: Mon, 8 Jun 1987 20:23 EDT
Message-ID: <RAM.12308975727.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
DTo: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: wither characters
In-reply-to: Msg of 8 Jun 1987 19:36-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Date: Monday, 8 June 1987 19:36-EDT
From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Re: wither characters
Let's see if I can summarize a bit:
The idea of using or depending on characters at the CLX level is less
than desirable to many people, for both semantic reasons and for
portability (CL doesn't require a 16-bit char-code-limit). It is more
desirable to stick strictly to an integer interface, and leave character
translation to the next higher level.
I think that it would be a bad idea to put this functionality in the
elusive (and possibly illusory) "next higher level". It is silly to
make your standard more portable by pushing implementation dependent
details into the user's code, when the reason for the standard is to
allow portable code to be written.
There should be a standard mechanism for displaying standard
characters. If the implementation supports interesting non-standard
characters, then the same mechanism should also do a reasonable job of
displaying them. I suggest that DRAW-STRING continue to exist, and
that it use 8 or 16 bit operations depending on whether the string is
fat or not.
Rob
∂09-Jun-87 1038 Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET Re: font-char-info
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 9 Jun 87 10:38:10 PDT
Received: from [128.89.1.80] by RELAY.CS.NET id ah00253; 9 Jun 87 13:26 EDT
Received: from ti-csl by RELAY.CS.NET id ad00559; 9 Jun 87 13:17 EDT
Received: by tilde id AA01774; Tue, 9 Jun 87 11:41:32 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 9 Jun 87 11:42:50 CDT
Message-Id: <2759244032-9000637@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 9 Jun 87 11:40:32 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
Subject: Re: font-char-info
In-Reply-To: Msg of Fri, 5 Jun 1987 12:03 EDT from "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
>It seems to me that the principal abstraction CLX should
>provide is a font of arbitrary size, indexed by an integer
>whose legal range is a function of that font. It is a trivial
>matter (best handled at the next level up?) to provide a
>translation function from the "natural" representation for any
>given alphabet into the single-integer value to be used with a
>certain font. For Japanese, this is presumably (+ (* 256
>first-byte) second-byte).
I'm inclined to agree with this point of view. However, since separate functions
for drawing out of 8-bit and 16-bit character sets are already ensconsed in the
Xv11 protocol, Japanese CLX'ers ought to be able to map directly to the
protocol, while the more uniform font abstraction advocated above ought to be
implemented within or upstream of CLX.
I accept the arguments of Moon and others that the translation of a CL character
into a CLX font-and-index will happen upstream and that char-width et al. should
therefore not accept character type arguments. RWS, I'll defer to your
understanding of Japanese requirements. From your description, it sounds like
ellipsis of the most-significant byte will not be important to Japanese users
anyway.
∂09-Jun-87 1358 @RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET Re: wither characters
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 9 Jun 87 13:58:36 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02116; 9 Jun 87 16:52 EDT
Received: from ti-csl by RELAY.CS.NET id aa01478; 9 Jun 87 16:46 EDT
Received: by tilde id AA02685; Tue, 9 Jun 87 12:18:53 CDT
Message-Id: <2759246377-10272632@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 9 Jun 87 12:19:37 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: cl-windows@SAIL.STANFORD.EDU
Subject: Re: wither characters
In-Reply-To: Msg of Mon, 8 Jun 1987 20:23 EDT from Ram@c.cs.cmu.edu
> Date: Mon, 8 Jun 1987 20:23 EDT
> From: Ram@c.cs.cmu.edu
> Subject: wither characters
>
> Date: Monday, 8 June 1987 19:36-EDT
> From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
> Re: wither characters
>
> Let's see if I can summarize a bit:
>
> The idea of using or depending on characters at the CLX level is less
> than desirable to many people, for both semantic reasons and for
> portability (CL doesn't require a 16-bit char-code-limit). It is more
> desirable to stick strictly to an integer interface, and leave character
> translation to the next higher level.
>
> I think that it would be a bad idea to put this functionality in the
> elusive (and possibly illusory) "next higher level". It is silly to
> make your standard more portable by pushing implementation dependent
> details into the user's code, when the reason for the standard is to
> allow portable code to be written.
AMEN! Why should CLX make life difficult for its users? I don't buy the
argument that "CHAR-CODES don't have anything to do with indexes in
fonts". Fonts aren't ordered randomly, and neither are CL char-codes.
Both are usually ASCII, and for good reasons.
In any case, the solution shouldn't be to disallow the use of character
objects (in strings or otherwise). How about adding an optional
translation table in the font object that maps char-codes to font
indices. That way, the translation can be done at a low level where
extra arrays won't have to be consed up.
;; On IBM machines, the default would be an EBCDIC to ASCII table...
(defparameter *default-font-mapping* nil
"Char-Code to Font-Index mapping, or NIL for 1 to 1")
(defun open-font (display name &key (cache-p t) (mapping *default-font-mapping*))
(declare (type display display)
(type stringable name)
(type boolean cache-p)
(type (or null vector) mapping)
(values font)))
(defun font-mapping (font)
;; setf'able
(declare (type font font)
(values (or null vector))))
I don't care much about the two-byte versus integer issue. Its as easy to
translate to one as the other.
∂09-Jun-87 1705 RWK@YUKON.SCRC.Symbolics.COM wither modularity
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87 17:05:11 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 221522; Tue 9-Jun-87 20:03:41 EDT
Date: Tue, 9 Jun 87 20:03 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: wither modularity
To: Ram@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12308975727.BABYL@>
Message-ID: <870609200327.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Mon, 8 Jun 1987 20:23 EDT
From: Ram@C.CS.CMU.EDU
Date: Monday, 8 June 1987 19:36-EDT
From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Re: wither characters
Let's see if I can summarize a bit:
The idea of using or depending on characters at the CLX level is less
than desirable to many people, for both semantic reasons and for
portability (CL doesn't require a 16-bit char-code-limit). It is more
desirable to stick strictly to an integer interface, and leave character
translation to the next higher level.
I think that it would be a bad idea to put this functionality in the
elusive (and possibly illusory)
Not elusive or illusory. As has already been pointed out, we can
create any portion of it we need, just by agreeing. (Unless you're
claiming that agreement is elusive and possibly illusory. I might
agree somewhat, but if so, why are we bothering with *this* level?)
"next higher level". It is silly to
make your standard more portable by pushing implementation dependent
details into the user's code, when the reason for the standard is to
allow portable code to be written.
But that's exactly you're proposing to do by using characters;
pushing implementation dependent details into the user's code.
The whole point of this exersize is to encapsulate the inherent
implementation dependencies (i.e. the nature of the fonts available),
and separate it out from the implementation-independent interface to
the communication protocol.
There should be a standard mechanism for displaying standard
characters. If the implementation supports interesting non-standard
characters, then the same mechanism should also do a reasonable job of
displaying them. I suggest that DRAW-STRING continue to exist, and
that it use 8 or 16 bit operations depending on whether the string is
fat or not.
If you read what I wrote, you'll see that I proposed a function which
takes standard (*and* non-standard) characters, and displays them. And it
figures out the best way of doing it. And it is part of the next-higher level.
And it is written in terms of this level, plus a function which converts from
characters to a font and an index.
It seems to me that what we bytes-instead-of-characters people are
arguing for is simply clear modularity and complete functionality,
not for taking away any convenience. There's no reason you have to
have the low-level interfaces be easy to use in a high-level way, when
you can have the high-level interfaces.
Rob
∂09-Jun-87 1739 MMcM@STONY-BROOK.SCRC.Symbolics.COM Higher levels
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87 17:39:12 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168834; Tue 9-Jun-87 20:36:54 EDT
Date: Tue, 9 Jun 87 20:36 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Higher levels
To: Ram@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12308975727.BABYL@>
Message-ID: <870609203644.9.MMCM@OWL.SCRC.Symbolics.COM>
If all layers higher than CLX elude us, how will programs do
WRITE-STRING or READ-CHAR from the windows they create?
I am afraid that once again some unwarranted assumptions are slipping in.
- that aspects of the interface @i(implementation) that are necessarily
system specific, such as scroll bars, **MORE** or other special handling
at the end of a screenful, cursor blinkers, and so on preclude any
agreement on the @i(specification).
- that the impossibility of completely specifying a stream interface to
windows necessarily leaves the poor programmers stuck with just the
lowest level bare X interface.
∂09-Jun-87 1803 @RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET Re: wither characters
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 9 Jun 87 18:03:19 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa03829; 9 Jun 87 20:24 EDT
Received: from ti-csl by RELAY.CS.NET id aa02593; 9 Jun 87 20:16 EDT
Received: by tilde id AA14680; Tue, 9 Jun 87 17:57:35 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 9 Jun 87 17:50:15 CDT
Message-Id: <2759266063-10324292@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 9 Jun 87 17:47:43 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: wither characters
In-Reply-To: Msg of Mon, 8 Jun 87 19:36 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Integers vs. characters:
While I agree that the CLX text/font functions should accept integers/integer
vectors and shouldn't depend on characters/strings, I wonder if there is any
objection to their *optional* use of character/string arguments? That is, for
programming convenience, any of these functions could accept a
character/string, automatically converting it to integer(s) using CHAR-CODE.
Wouldn't this permit a productive convenience without really blurring the
distinction between the CL and X concepts of a character? Wouldn't this also
permit CLX to mesh with the upstream translation of CL character objects into
font/index pairs?
Matrix vs. linear character indexing:
Given the Japanese requirements for first-byte/second-byte interfaces and the
existence of such interfaces already in the Xv11 protocol, I feel that CLX
should also provide matrix indexing interfaces. It seems silly to *require*
unnecessary packing/unpacking of char2b's. Someone (Fahlman?) indicated
that other CLX users might not be satisfied with the conventional conversion
from 16-bit integer to first-byte/second-byte; matrix indexing would appeal
also to such users. I guess I'm arguing for draw-string16, etc. with :bytes-p,
as the spec currently says.
∂09-Jun-87 1810 RWK@YUKON.SCRC.Symbolics.COM Re: wither characters
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87 18:09:46 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 221574; Tue 9-Jun-87 21:07:51 EDT
Date: Tue, 9 Jun 87 21:07 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: wither characters
To: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2759246377-10272632@SI>
Message-ID: <870609210739.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Tue, 9 Jun 87 12:19:37 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
> I think that it would be a bad idea to put this functionality in the
> elusive (and possibly illusory) "next higher level". It is silly to
> make your standard more portable by pushing implementation dependent
> details into the user's code, when the reason for the standard is to
> allow portable code to be written.
AMEN! Why should CLX make life difficult for its users? I don't buy the
argument that "CHAR-CODES don't have anything to do with indexes in
fonts". Fonts aren't ordered randomly, and neither are CL char-codes.
Both are usually ASCII, and for good reasons.
"Usually" ain't good enough to build a standard on. On our system,
CHAR-CODE's are not ASCII, and in fact, the high 8 bits are assigned
in order of loading of the individual character-set. Is that random
enough for you?
I can guarentee you that if you don't deal with the font ordering
issue, incompatibilities are going to make life a LOT harder for
CLX users and the users of what CLX's users build.
In any case, the solution shouldn't be to disallow the use of character
objects (in strings or otherwise). How about adding an optional
translation table in the font object that maps char-codes to font
indices.
What about the CHAR-CODE's that don't map to this font, but instead to
some other font? I.e. what if this font implements the standard character
set, but the char-code involved is for a Kanji character?
By the time you've chosen the font, it's too late to be dealing with
CHAR-CODE's.
That way, the translation can be done at a low level where
extra arrays won't have to be consed up.
The higher level wouldn't have to cons up arrays on the fly.
;; On IBM machines, the default would be an EBCDIC to ASCII table...
(defparameter *default-font-mapping* nil
"Char-Code to Font-Index mapping, or NIL for 1 to 1")
(defun open-font (display name &key (cache-p t) (mapping *default-font-mapping*))
(declare (type display display)
(type stringable name)
(type boolean cache-p)
(type (or null vector) mapping)
(values font)))
(defun font-mapping (font)
;; setf'able
(declare (type font font)
(values (or null vector))))
I don't care much about the two-byte versus integer issue. Its as easy to
translate to one as the other.
∂09-Jun-87 2122 RAM@C.CS.CMU.EDU Higher levels
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Jun 87 21:22:43 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 10 Jun 87 00:22:00-EDT
Date: Wed, 10 Jun 1987 00:21 EDT
Message-ID: <RAM.12309281349.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Higher levels
In-reply-to: Msg of 9 Jun 1987 20:36-EDT from Mike McMahon <MMcM at STONY-BROOK.SCRC.Symbolics.COM>
I question the meaningfulness of defining a "level" which can only be
used to define another "level". I will go along with the widely
expressed belief that "nobody will want to use CLX directly", but I
think that it should be possible to write programs that run without
modification in any Common Lisp that supports CLX. If there is a
standard mechanism for displaying standard characters, then
programs that run in the intersection of Common Lisp and common X will
port without difficulty. There are major applications that fall in
this category, for example the Hemlock text editor.
I guess that Hemlock is in some sense a "higher level" and perhaps
even a "toolkit" (heaven forbid). You can use these terms if they
make you feel better, but it doesn't change the issues at all. There
are many programs that are perfectly happy living directly on top of
CLX as long as there is some way to display characters in a window. I
certainly don't buy arguments that I should wait for a "stream
oriented higher level". Only a truly warped mind would perceive
incremental bitmap redisplay as being stream oriented.
If it is really true that nobody will directly use CLX, then its only
reason for existence is to allow portable "toolkits" to be written.
It seems that we should be giving some consideration to what these
"higher layers" will want.
Rob
∂09-Jun-87 2304 Masinter.pa@Xerox.COM multi-byte characters and Japanese
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87 23:04:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 22:59:06 PDT
Date: 9 Jun 87 22:58 PDT
From: Masinter.pa@Xerox.COM
Subject: multi-byte characters and Japanese
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870609-225906-2187@Xerox>
The Japanese working group on character encoding sent out a mailing on
18 May to common-lisp@sail.stanford.edu proposing a way of dealing with
Japanese characters in Common Lisp. This proposal did not talk about
multiple bytes, high-bytes and low-bytes, but rather, extending
char-code-limit to be able to handle Japanese.
It would seem most reasonable, if one is worrying about encoding
Japanese characters, to attempt some compatibility with that proposal,
wouldn't you think?
∂10-Jun-87 1553 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU the character of characters
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87 15:53:35 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 10 Jun 87 18:26-EDT
Date: Wed, 10 Jun 87 18:23 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: the character of characters
To: cl-windows@sail.stanford.edu
Message-ID: <870610182346.5.RWS@KILLINGTON.LCS.MIT.EDU>
The issues surrounding characters vs. integers and linear vs. matrix
will be highest on my list of things to bring up before X3J13 at the end
of June (I've asked to make a presentation, to get their feedback).
Ignoring the matrix part, I wonder if we could get around the character
vs. integer part by generalizing the interface even further, along the
following lines:
(defun draw-string (drawable gcontext x y sequence &key (start 0) end (transform 'identity))
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end)
(type (function (t) integer) transform)))
(Ignore whether draw-string is still a good name.) That is, it takes in
a sequence of "things" and a function that turns "things" into (8-bit
font) indexes. [Please don't suggest that transform also return a
font.] Compiler and/or run-time optimizations could take care of special
cases like
(array (unsigned-byte 8)) with identity
string with char-code
...
Similar generalizations could be applied to draw-string16, etc.
∂10-Jun-87 2125 MMcM@STONY-BROOK.SCRC.Symbolics.COM Higher levels
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 21:25:30 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169874; Wed 10-Jun-87 20:19:11 EDT
Date: Wed, 10 Jun 87 20:19 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Higher levels
To: Ram@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12309281349.BABYL@>
Message-ID: <870610201910.0.MMCM@OWL.SCRC.Symbolics.COM>
Doubting levels that only implement higher levels could be taken as an
argument against microcoding, ISO/OSI, compilers, and RISC
architectures, among other things. I think I see your point, though.
I agree that a text editor often has large pieces that can be used as
toolkits. I am not sure that this lessens my point, though.
A bitmap screen redisplay sounds like a client of a object-oriented
stream interface to me. The generic hierarchical one we have certainly
makes great use of actor encapsulation.
When building a program with the highest degree of portability,
several possibilities are open, for instance in how that program
interfaces to the terminal driver's BitBlt/RasterOp capabilities
necessary for getting redisplay done.
(1) implement in CLX and make the program available to all the systems
which support that, which we can assume will be a large number as time
goes on.
(2) supply a separate module of system dependent functions which must
be conditionally linked in depending on the environment.
(3) make the primitive shifting operations generic operations on streams.
Now strategy (3) walks a fine line between wanting to make the operation
higher level, thereby capturing your intentions more closely, and
insulating yourself as much as possible from the operating system
environment and requiring the operating system to supply what is
logically part of a particular application program, in this case a text
editor. For this reason, it appears harder to pin down than just the
bare bones console real-estate manager. But in the long run, it is this
which leads to a easier development of a wider range of applications.
No one is proposing that you wait until everything is done to get your
work done. Just that you and everyone else might benefit from trying to
take the perspective: which part of what I have here really should be
part of the stream protocol?
∂10-Jun-87 2126 Moon@STONY-BROOK.SCRC.Symbolics.COM the character of characters
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 21:26:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169941; Wed 10-Jun-87 22:29:12 EDT
Date: Wed, 10 Jun 87 22:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: the character of characters
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@sail.stanford.edu
In-Reply-To: <870610182346.5.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870610222906.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 10 Jun 87 18:23 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Ignoring the matrix part, I wonder if we could get around the character
vs. integer part by generalizing the interface even further, along the
following lines:
(defun draw-string (drawable gcontext x y sequence &key (start 0) end (transform 'identity))
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end)
(type (function (t) integer) transform)))
(Ignore whether draw-string is still a good name.)
How about draw-character-sequence? I'd suggest draw-poly-chars instead,
except that in my out of date copy of the X11 spec "poly text" is something
different (does that still exist? It looks completely different from
anything in CLX.)
That is, it takes in
a sequence of "things" and a function that turns "things" into (8-bit
font) indexes. [Please don't suggest that transform also return a
font.]
I'm afraid I do have to suggest that. Actually, a better idea is to give
transform a way to say "stop before this character", maybe by returning NIL.
Then draw-string would return three values describing how to continue
the operation: the index into the sequence, x, and y. The first value would
be NIL if the whole sequence was output. Of course this isn't strictly
necessary, since one could pre-scan the sequence to find font changes and
then call draw-string on each sub-sequence. But if you're going to do that,
why bother with the transform funarg at all? Since there was objection to
just making the caller of draw-string compute a sequence of integers in the
first place, presumably there would be objection to pre-scanning the sequence.
A perhaps minor problem with this proposal is that it encourages
programmers to screw themselves by writing :transform #'char-code, which
is not actually portable (although it probably works in more than one
implementation).
Except for those two problems, this sounds like a workable proposal.
∂11-Jun-87 0808 sas@bfly-vax.bbn.com Re: the character of characters
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 08:08:01 PDT
Date: Thu, 11 Jun 87 10:04 EDT
From: Seth Steinberg <sas@bfly-vax.bbn.com>
Subject: Re: the character of characters
To: cl-windows@sail.stanford.edu
Forgive my extreme naivite, but I am getting mixed signals from this
character code debate.
1) One group has designed a very nice, very general interface which
handles characters at their most general and would let me draw words
like "naivite" with the correct umlauts and accents. They would rather
not have the specification burdened with numerous machine, character
set and language dependencies. They propose a lower level and want
things like (princ "foo") handled somewhere else.
Their big FEAR: ASCII somehow gets embedded (nay lodged) in CLX.
This defeats portability at the CLX level.
2) The other group would like to be able to draw ASCII (or EBCDIC)
characters in an X window given a location, a font and so on. They
reason that this seems to be a very common operation given that many
people run CL programs to get output. Since the language supports
strings and a set of string operations, should CLX support CL string
output.
Their big FEAR: Each CL implementation has its own set of routines to
write characters into X windows. This defeats portability at the CL
level.
----
My impression is that some higher level character code oriented
primitive should be specified in the CLX description even if its
implementation is not. This should specify something below EMACS but
safely above the level of actual font indices. Given certain biases,
it should handle things like #\a and "foo". If there is enough
interest and knowledge available it should handle Kanji as well.
----
Actually, this kind of looks like what the most recent messages are
iterating in on.
Baffled in Boston,
Seth
sas@bbn.com
∂12-Jun-87 1221 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU the character of characters
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87 12:21:31 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 Jun 87 14:33-EDT
Date: Fri, 12 Jun 87 14:34 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: the character of characters
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@sail.stanford.edu
In-Reply-To: <870610222906.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870612143408.9.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 10 Jun 87 22:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
(defun draw-string (drawable gcontext x y sequence &key (start 0) end (transform 'identity))
How about draw-character-sequence?
How about draw-glyphs?
I'd suggest draw-poly-chars instead,
except that in my out of date copy of the X11 spec "poly text" is something
different (does that still exist? It looks completely different from
anything in CLX.)
There is also draw-text in CLX, which mirrors the PolyText request. I
would propose giving it a :transform in the same way (but again I don't
know what to do about naming).
That is, it takes in
a sequence of "things" and a function that turns "things" into (8-bit
font) indexes. [Please don't suggest that transform also return a
font.]
I'm afraid I do have to suggest that. Actually, a better idea is to give
transform a way to say "stop before this character", maybe by returning NIL.
Then draw-string would return three values describing how to continue
the operation: the index into the sequence, x, and y. The first value would
be NIL if the whole sequence was output. Of course this isn't strictly
necessary, since one could pre-scan the sequence to find font changes and
then call draw-string on each sub-sequence. But if you're going to do that,
why bother with the transform funarg at all? Since there was objection to
just making the caller of draw-string compute a sequence of integers in the
first place, presumably there would be objection to pre-scanning the sequence.
Even if a pre-scan is necessary, the reason for the transform is to
avoid the necessity of copying from the application object (string,
etc.) to some temporary array of integers (where does it come from?)
and then to the output buffer inside CLX; the transform lets (but
doesn't require, of course) CLX go directly from application object to
output buffer.
Pre-scanning is often going to be necessary, e.g. to enforce a right
margin, etc. There will be a performance trade-off between pre-scanning
and using a lexical closure for the funarg to track the width. However,
I'm not opposed to allowing the transform return nil to indicate the
end, and having draw-string return the last index.
I don't believe the (x,y) coordinates should be returned, however. One
major reason is that we don't currently require CLX to have the
per-glyph metrics available locally, and requiring that would cause
extreme problems. In many cases the application will have to precompute
the width before doing the output, so having CLX do it again is useless.
If you don't want to pre-scan but want to maintain a right margin or
something, a closure as the transform can calculate and retain the
width.
However, related to this is the current comment in draw-string:
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached.
In order to be clever, draw-string does indeed need to know the width of
the string, in order to cache the ending position. What I would propose
is that draw-string take another keyword argument :width (or perhaps
:ending-x instead) that CLX would *believe* if provided. If provided,
CLX could be clever about appending a subsequent call onto this one. If
not provided, CLX might or might not be clever (unspecified; e.g., might
be clever if metrics are known locally). Thus, we end up with something
like:
(defun draw-glyphs (drawable gcontext x y sequence
&key (start 0) end (transform 'identity) width)
;; The transform is used to convert an element of the sequence into a
;; font index. The transform is applied to each element of the
;; (sub)sequence, until either the transform returns nil or the end of
;; the (sub)sequence is reached. If transform returns nil for an
;; element, the index of that element in the sequence is returned,
;; otherwise nil is returned. If width is specified, it is assumed to
;; be the pixel width of whatever string of glyphs is actually drawn,
;; which will allow for appending the output of a subsequent
;; draw-glyphs to the same protocol request, provided gcontext has not
;; been modified in the interim. If width is not specified, appending
;; for subsequent draw-glyphs might not occur. Specifying width is
;; simply a hint, for performance.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type (function (t) (or null integer)) transform))
(values (or null integer)))
I'm unclear about whether returning nil is better than returning (1+ end).
A perhaps minor problem with this proposal is that it encourages
programmers to screw themselves by writing :transform #'char-code, which
is not actually portable (although it probably works in more than one
implementation).
Well, I think it can be argued that those who want to screw themselves
will do it with or without our encouragement. If you don't provide a
way, they will just find their own non-portable way to do it. The fact
that a general mechanism can be abused doesn't bother me. Rather, in
those cases where the higher level can determine that the characters of
a string all fall into the intersection of the local CL character set
and the character set of the font, being able to transform with
char-code seems like a win. In some systems, CLX can then directly blit
from the string to the output buffer (e.g., with the aid of displaced
arrays and type conversions).
∂12-Jun-87 1516 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU font and character metrics
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87 15:16:05 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 Jun 87 18:05-EDT
Date: Fri, 12 Jun 87 18:05 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: font and character metrics
To: cl-windows@sail.stanford.edu
Message-ID: <870612180544.2.RWS@KILLINGTON.LCS.MIT.EDU>
It seems to me the best solution about linear vs. matrix for getting at
metrics is to keep the two interfaces separate. I'm happy for now to
only define the linear interface, and wait until there is clear desire
and need before adding a matrix interface. Assuming that we make the
transformer change to draw-string, etc., I think it is acceptable to
eliminate explicit character indexing, and force that transformation on
the caller. To first order, that just means having accessors of the
form:
(defun char-<metric> (font index)
(declare (type font font)
(type integer index)
(values integer)))
I'm happy to have separate character metric functions like this, and
eliminate fetching of char-info objects. (BTW, should this return nil
for an out-of-bounds index, or zero, or signal?)
I'm less sure on whether it is better to handle min- and max-bounds by
allowing :min and :max as an index, or by 12 accessors on the font, or
by retaining a char-info object (perhaps renamed as bounds-info) solely
for this purpose.
In thinking about what to do with font-info objects, I've changed my
mind about the "hackery" of having pseudo- font objects. We can have
list-fonts-with-info return real font objects, but have the actual
open-font equivalent (to assign it a resource-id) take place dynamically
under the covers at the first use that requires it. In normal usage
this provides a seamless interface, but it will be necessary to
introduce an illegal-font condition to signal in the case where the
delayed open-font fails (e.g., due to a change in the font path) and on
any subsequent calls that would require using the resource-id. This
condition should be rare enough that the overall interface seems
acceptable.
As I mentioned in previous mail, the protocol supports the ability to
query all of the font metrics given a gcontext (that contains a font).
If we are to provide this in CLX, then I guess we return a font object
that will likewise cause an illegal-font condition when used improperly.
Since there is already a gcontext-font accessor (returning nil or a
font), we might change it slightly (so that we don't cons up font
objects needlessly):
(defun gcontext-font (gcontext &optional metrics-p)
;; If the stored font is known, it is returned. If it is not known
;; and metrics-p is false, then nil is returned. If it is not known
;; and metrics-p is true, then a font is returned containing the
;; metric information, but this font will cause an error if used
;; in [enumerate the bad ways to use it].
(declare (type gcontext gcontext)
(type boolean metrics-p)
(values (or null font))))
Comments on all this, please?
∂12-Jun-87 2047 RWK@YUKON.SCRC.Symbolics.COM multi-byte characters and Japanese
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 12 Jun 87 20:47:30 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223689; Fri 12-Jun-87 23:46:33 EDT
Date: Fri, 12 Jun 87 23:46 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: multi-byte characters and Japanese
To: Masinter.pa@Xerox.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870609-225906-2187@Xerox>
Message-ID: <870612234615.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: 9 Jun 87 22:58 PDT
From: Masinter.pa@Xerox.COM
The Japanese working group on character encoding sent out a mailing on
18 May to common-lisp@sail.stanford.edu proposing a way of dealing with
Japanese characters in Common Lisp. This proposal did not talk about
multiple bytes, high-bytes and low-bytes, but rather, extending
char-code-limit to be able to handle Japanese.
It would seem most reasonable, if one is worrying about encoding
Japanese characters, to attempt some compatibility with that proposal,
wouldn't you think?
Unfortunately, it doesn't really relate, because it's dealing with
characters, and doesn't even specify the character-code. We're dealing
with integers or bytes here. I don't think their absence in the proposal
has any bearing on CLX, except to highlight the different levels.
∂13-Jun-87 1434 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU more concrete font proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Jun 87 14:34:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Jun 87 17:32-EDT
Date: Sat, 13 Jun 87 17:33 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: more concrete font proposal
To: cl-windows@sail.stanford.edu
Message-ID: <870613173320.8.RWS@KILLINGTON.LCS.MIT.EDU>
Putting everything together, the following is an attempt to put together
the various ideas that have been discussed, and provide the complete
font-related interface. Comments most welcome.
;; Note: font-info defstruct is removed.
(defun open-font (display name)
;; Font objects may be cached and reference counted locally within the display
;; object. This function might not execute a with-display if the font is cached.
;; The protocol QueryFont request happens on-demand under the covers.
(declare (type display display)
(type stringable name)
(type boolean cache-p)
(values font)))
;; Note: font-cache-p and setf are removed as no longer sensible (given the
;; inability to extract a font-info object).
(defun discard-font-info (font)
;; Discards any state that can be re-obtained with QueryFont. This is simply
;; a performance hint for memory-limited systems.
(declare (type font font)))
;; This can be signalled anywhere a pseudo font access fails.
(define-condition invalid-font error
font)
;; Note: font-font-info removed.
(defun font-name (font)
;; Returns nil for a pseudo font returned by gcontext-font.
(declare (type font font)
(values (or null string))))
(defun font-direction (font)
(declare (type font font)
(values draw-direction)))
(defun font-min-char (font)
(declare (type font font)
(values integer)))
(defun font-max-char (font)
(declare (type font font)
(values integer)))
(defun font-min-byte1 (font)
(declare (type font font)
(values integer)))
(defun font-max-byte1 (font)
(declare (type font font)
(values integer)))
(defun font-min-byte2 (font)
(declare (type font font)
(values integer)))
(defun font-max-byte2 (font)
(declare (type font font)
(values integer)))
(defun font-all-chars-exist-p (font)
(declare (type font font)
(values boolean)))
(defun font-default-char (font)
(declare (type font font)
(values integer)))
(defun font-ascent (font)
(declare (type font font)
(values integer)))
(defun font-descent (font)
(declare (type font font)
(values integer)))
;; The list contains alternating keywords and integers.
(deftype font-props () 'list)
(defun font-properties (font)
(declare (type font font)
(values font-props)))
(defun font-property (font name)
(declare (type font font)
(type keyword name)
(values (or null integer))))
;; For each of left-bearing, right-bearing, width, ascent, descent, attributes:
(defun char-<metric> (font index)
;; Note: I have tentatively chosen to return nil for an out-of-bounds index
;; (or an in-bounds index on a pseudo font), although returning zero or
;; signalling might be better.
(declare (type font font)
(type integer index)
(values (or null integer))))
(defun max-char-<metric> (font)
;; Note: I have tentatively chosen separate accessors over allowing :min and
;; :max as an index above.
(declare (type font font)
(values integer)))
(defun min-char-<metric> (font)
(declare (type font font)
(values integer)))
;; Note: char16-<metric> accessors could be defined to accept two-byte indexes.
(defun close-font (font)
;; This might not generate a protocol request if the font is reference
;; counted locally or if it is a pseudo font.
(declare (type font font)))
(defun list-font-names (display pattern &key (max-fonts 65535) (result-type 'list))
;; Note: Was called list-fonts, but that name is better used below.
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence string))))
(defun list-fonts (display pattern &key (max-fonts 65535) (result-type 'list))
;; Note: Was called list-fonts-with-info.
;; Returns "pseudo" fonts that contain basic font metrics and properties, but
;; no per-character metrics and no resource-ids. These pseudo fonts will be
;; converted (internally) to real fonts dynamically as needed, by issuing an
;; OpenFont request. However, the OpenFont might fail, in which case the
;; invalid-font error can arise.
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence font))))
(defun gcontext-font (gcontext &optional metrics-p)
;; If the stored font is known, it is returned. If it is not known and
;; metrics-p is false, then nil is returned. If it is not known and
;; metrics-p is true, then a pseudo font is returned. Full metric and
;; property information can be obtained, but the font does not have a name or
;; a resource-id, and attempts to use it where a resource-id is required will
;; result in an invalid-font error.
(declare (type gcontext gcontext)
(type boolean metrics-p)
(values (or null font))))
;; A transform8 produces a single 8-bit index, or nil for termination.
(deftype transform8 () '(function (t) (or null integer)))
;; A transform16 produces nil for termination, (integer nil) for a linear
;; 16-bit index, and (integer integer) for a two-byte matrix index.
(deftype transform16 () '(function (t) (or null integer) (or null integer)))
;; In the functions below, the transform is used to convert an element of the
;; sequence into a font index. The transform is applied to each element of the
;; (sub)sequence, until either the transform returns nil or the end of the
;; (sub)sequence is reached. If transform returns nil for an element, the
;; index of that element in the sequence is returned, otherwise nil is
;; returned.
;; In the functions below, if width is specified, it is assumed to be the pixel
;; width of whatever string of glyphs is actually drawn. Specifying width will
;; allow for appending the output of subsequent calls to the same protocol
;; request, provided gcontext has not been modified in the interim. If width
;; is not specified, appending of subsequent output might not occur.
;; Specifying width is simply a hint, for performance. Note that specifying
;; width may be difficult if transform can return nil.
(defun text-extents (font sequence &key (start 0) end (transform 'identity))
(declare (type (or font gcontext) font)
(type sequence sequence)
(type transform16 transform)
(values width ascent descent left right font-ascent font-descent direction
(or null integer))))
(defun text-width (font sequence &key (start 0) end (transform 'identity))
(declare (type (or font gcontext) font)
(type sequence sequence)
(type transform16 transform)
(values integer (or null integer))))
(defun draw-glyph (drawable gcontext x y index &optional width)
;; Use &key for consistency?
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer (x y index))
(type (or null integer) width)))
(defun draw-glyphs (drawable gcontext x y sequence
&key (start 0) end (transform 'identity) width)
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type transform8 transform)
(values (or null integer))))
(defun draw-image-glyph (drawable gcontext x y index &optional width)
;; Use &key for consistency?
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer (x y index))
(type (or null integer) width)))
(defun draw-image-glyphs (drawable gcontext x y sequence
&key (start 0) end (transform 'identity) width)
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type transform8 transform)
(values (or null integer))))
;; Note: I am unsure how to define draw-glyph16 and draw-image-glyph16.
;; Note: a possible alternative to the following would be to provide both
;; :transform8 and :transform16 keyword arguments to draw-glyphs and
;; draw-image-glyphs.
(defun draw-glyphs16 (drawable gcontext x y sequence
&key (start 0) end (transform 'identity) width)
;; Only differs from draw-glyphs in transform type.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type transform16 transform)
(values (or null integer))))
(defun draw-image-glyphs16 (drawable gcontext x y sequence
&key (start 0) end (transform 'identity) width)
;; Only differs from draw-glyphs in transform type.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type transform16 transform)
(values (or null integer))))
;; Note: I haven't figured out what to do with draw-text (and draw-text16). It
;; may be that their existing definitions aren't really very useful. It may be
;; better to provide a function that takes a transform of the form:
;; (function t (or null integer) (or null font) (or null integer))
;; where the first value is the index, the second is optionally a change in
;; font, and the third is optionally a delta in x coordinate.
∂15-Jun-87 0912 @RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET Re: more concrete font proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 15 Jun 87 09:12:44 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ak00342; 15 Jun 87 11:52 EDT
Received: from ti-csl by RELAY.CS.NET id ag10051; 15 Jun 87 11:17 EDT
Received: by tilde id AA20745; Mon, 15 Jun 87 10:14:41 CDT
Message-Id: <2759757310-3394403@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 15 Jun 87 10:15:10 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: more concrete font proposal
In-Reply-To: Msg of Sat, 13 Jun 87 17:33 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
I like the parts of your proposal related to font and char info. I have
some concerns about using closures for string transformations. By
having the transformation return NIL when a font change is required, all
you've done is shove the font problem up to the next level. If I write
a toolkit on top of CLX, it can't be portable, because all the places
that use CLX functions taking transform arguments will have to be
modified (what's the right thing to do when the transform function
returns NIL?). It sure would be nice if we could agree on how to
display multi-fonted text in CLX, rather than making every toolkit
re-invent it.
I agree with Robert Kerns and Seth Steinberg's suggestions that an
implementation dependent function be specified for translating character
objects into font/index pairs. I.E.
(deftype font-list () '(or font gcontext (sequence (or font gcontext))))
(defun char-font-and-index (font-list character)
;; Implementation dependent function for translating CL character objects
;; font-list is a sequence used to provide information about what font
;; to use given (char-font character) and (char-code character)
(declare (type font-list font-list)
(type character character)
(inline char-font-and-index))
(values index font))
(defun text-extents (fonts string)
(declare (type font-list fonts)
(type (or string (vector character)) string)
(inline char-font-and-index)
(values width ascent descent left right font-ascent font-descent direction)))
(defun draw-string (drawable gcontext x y string &key (start 0) end fonts)
;; For 8-bit indexes only.
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type (or string (vector character)) string)
(type (or null integer) end)
(type font-list fonts)
(inline char-font-and-index)))
Perhaps a font-list slot could be added to the gcontext object? This
would ensure that the char-font-and-index function could easily get
a font-list, even when a toolkit maker didn't bother to pass the
font-list parameter around to all the string drawing functions.
∂15-Jun-87 1435 @RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET Re: more concrete font proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 15 Jun 87 14:35:01 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac02531; 15 Jun 87 16:36 EDT
Received: from ti-csl by RELAY.CS.NET id ac11577; 15 Jun 87 16:31 EDT
Received: by tilde id AA28552; Mon, 15 Jun 87 14:26:39 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 15 Jun 87 14:28:11 CDT
Message-Id: <2759772249-7706533@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 15 Jun 87 14:24:09 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: more concrete font proposal
In-Reply-To: Msg of Sat, 13 Jun 87 17:33 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Handling out-of-bounds index in char-<metric>:
Signalling an error would be appropriate. Since sufficient info to avoid the
error is available, an out-of-bounds index is a coding flub.
:max/:min vs separate accessors:
Agree that separate accessors is better. Better to know the max/min integer
since this could conceivably be useful in counting or in setting up loops.
&key width for draw-glyph:
Yes, for consistency's sake.
draw-text
Seems to me the PolyText request is designed to performed "formatted"
output, such as multiple columns or fully-justified lines of text (perhaps
the latter is the real intent of the request). In this case, having
separate draw-glyph calls rediscover how to append themselves together again
constitutes a bit of ring-around-the-rosie. Is this a serious problem? The
:widths approach is actually a superior interface for laying out columns.
If fully-justified text output is in sufficient demand to warrant a special
interface, then I'm not sure if the 3-valued transform you suggested is the
best way. Better something like the current draw-text, with its precomputed
sequence of fonts, deltas, and indexes.
∂17-Jun-87 1300 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: more concrete font proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 13:00:35 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Jun 87 15:57-EDT
Date: Wed, 17 Jun 87 15:57 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2759757310-3394403@SI>
Message-ID: <870617155712.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Mon, 15 Jun 87 10:15:10 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
I like the parts of your proposal related to font and char info. I have
some concerns about using closures for string transformations.
I don't see that a closure, as opposed to a simple function, is
necessarily involved. An application dealing with strings, as opposed
to (vector character), doesn't require a closure, it simply requires a
character-set translation.
By
having the transformation return NIL when a font change is required, all
you've done is shove the font problem up to the next level.
It isn't necessarily a font change, it can also be due to format control
(space, tab, newline, even ~ directives).
If I write
a toolkit on top of CLX, it can't be portable, because all the places
that use CLX functions taking transform arguments will have to be
modified (what's the right thing to do when the transform function
returns NIL?).
I don't understand this at all, and certainly not if the "CLX functions"
you think have to be modified are things like draw-glyphs. Perhaps you
could give a concrete example?
It sure would be nice if we could agree on how to
display multi-fonted text in CLX, rather than making every toolkit
re-invent it.
I'm no longer convinced that characters will necessarily be the only
"source" for text output. This doesn't preclude agreeing on a
character-translation interface, but it can argue against characters
being the only interface.
I agree with Robert Kerns and Seth Steinberg's suggestions that an
implementation dependent function be specified for translating character
objects into font/index pairs. I.E.
(deftype font-list () '(or font gcontext (sequence (or font gcontext))))
(defun char-font-and-index (font-list character)
;; Implementation dependent function for translating CL character objects
;; font-list is a sequence used to provide information about what font
;; to use given (char-font character) and (char-code character)
(declare (type font-list font-list)
(type character character)
(inline char-font-and-index))
(values index font))
I don't see how this has a prayer of working. An "implementation
dependent" function, as near as I can tell, will be "dependent" on the
particular CL implementation of characters, but cannot be "dependent" on
a particular X server or font set. That *might* give you a good enough
handle to determine what the local character set is, but as far as I can
tell it doesn't give you *any* clue to what the character sets employed
by the particular fonts are. I don't know of any way to hide/solve this
problem, except by mandating that CLX will only work with fonts with
particular characteristics.
How many non-lispm CL implementations actually have a non-zero
char-font-limit? Does anyone really agree on the use of font
attributes? How can one write portable code in this environment, except
by avoiding character objects?
∂17-Jun-87 1310 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: more concrete font proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 13:10:42 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Jun 87 16:10-EDT
Date: Wed, 17 Jun 87 16:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2759772249-7706533@Sierra>
Message-ID: <870617161017.9.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Mon, 15 Jun 87 14:24:09 CDT
draw-text
Seems to me the PolyText request is designed to performed "formatted"
output, such as multiple columns or fully-justified lines of text (perhaps
the latter is the real intent of the request).
Spacing between words is the real intent.
In this case, having
separate draw-glyph calls rediscover how to append themselves together again
constitutes a bit of ring-around-the-rosie. Is this a serious problem? The
:widths approach is actually a superior interface for laying out columns.
If fully-justified text output is in sufficient demand to warrant a special
interface, then I'm not sure if the 3-valued transform you suggested is the
best way. Better something like the current draw-text, with its precomputed
sequence of fonts, deltas, and indexes.
I guess this depends on whether you think the application is likely to keep data
structures in that particular form (which either means the application is fairly
X specific or else the "application" is really an X toolkit that is additionally
buffering output) or simply recompute output on the fly.
∂17-Jun-87 1341 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU re: pseudo fonts
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 13:41:22 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Jun 87 16:33-EDT
Date: Wed, 17 Jun 87 16:34 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: re: pseudo fonts
To: cl-windows@sail.stanford.edu
Message-ID: <870617163409.0.RWS@KILLINGTON.LCS.MIT.EDU>
From: anon
I'm not sure of this pseudo-font stuff.
I agree; I'm not particularly happy with it either. My hope is that
seeing the stuff written down might lead to some ideas.
I guess if it's a strict
requirement that all protocol facilities be available from the library,
you need it. If not, I'd think of supplying a GC as just a convenience
that could be foregone in this language binding.
The major reason the protocol allows querying via the gcontext is to let
the application get at the "default font" initially stored in the
gcontext; a particularly trivial application could decide to just use
it, without opening a font explicitly. I don't know if this is a very
compelling argument, or whether it is worth the interface complexity to
mirror it.
Short of eliminating pseudo fonts, I suppose another possibility would
be to retain font-info objects (but not as explicit defstructs), and
change appropriate accessors to accept (or font font-info) as arguments.
∂18-Jun-87 0652 sas@bfly-vax.bbn.com Re: more concrete font proposal
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 18 Jun 87 06:52:00 PDT
Date: Thu, 18 Jun 87 08:43 EDT
From: Seth Steinberg <sas@bfly-vax.bbn.com>
Subject: Re: more concrete font proposal
To: cl-windows@sail.stanford.edu
Mr. Scheifler has raised a valid point and I believe partially answered
it:
> I don't see how this has a prayer of working. An "implementation
> dependent" function, as near as I can tell, will be "dependent" on the
> particular CL implementation of characters, but cannot be "dependent" on
> a particular X server or font set. That *might* give you a good enough
> handle to determine what the local character set is, but as far as I can
> tell it doesn't give you *any* clue to what the character sets employed
> by the particular fonts are. I don't know of any way to hide/solve this
> problem, except by mandating that CLX will only work with fonts with
> particular characteristics.
>
> ... Does anyone really agree on the use of font attributes? ...
Since fonts are used for all sorts of things, not just displaying
ASCII, it might be a good idea to recognize this fact and have some
kind of "font attribute" which tells how well the font (or font set,
when necessary) handles displaying ASCII (e.g. :alphanumeric :printing
:national <xxx> (as opposed to ASCII which is American) and so on).
I'll assume that other parties can concentrate on how to display Kanji,
or Hindi, or Space War.
It would be real nice if the windows standard provided some system
independent means of displaying the characters in the Common Lisp
"standard character set" as described in section 2.2 of Steele's Common
Lisp book. Ah, life was some much simpler in the good old days:
WRITE (6,23)
23 FORMAT(14HGOOD OLD DAYS!)
Seth
∂18-Jun-87 0940 @RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET Re: more concrete font proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Jun 87 09:40:25 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07966; 18 Jun 87 11:40 EDT
Received: from ti-csl by RELAY.CS.NET id ab01285; 18 Jun 87 11:31 EDT
Received: by tilde id AA12223; Thu, 18 Jun 87 09:34:16 CDT
Message-Id: <2760014046-3641752@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Thu, 18 Jun 87 09:34:06 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: more concrete font proposal
In-Reply-To: Msg of Wed, 17 Jun 87 15:57 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
> Date: Wed, 17 Jun 87 15:57 EDT
> From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
> Subject: Re: more concrete font proposal
>
> By
> having the transformation return NIL when a font change is required, all
> you've done is shove the font problem up to the next level.
>
> It isn't necessarily a font change, it can also be due to format control
> (space, tab, newline, even ~ directives).
Good point. I forgot about that.
> If I write
> a toolkit on top of CLX, it can't be portable, because all the places
> that use CLX functions taking transform arguments will have to be
> modified (what's the right thing to do when the transform function
> returns NIL?).
>
> I don't understand this at all, and certainly not if the "CLX functions"
> you think have to be modified are things like draw-glyphs. Perhaps you
> could give a concrete example?
Perhaps I'm trying to solve a nonexistent problem. I got the impression
from Moon and Kerns that its probable that a lisp's character set
couldn't be represented with a single font. For example, #\alpha would
be in a different font from #\a. If a transform function returns NIL on
the #\alpha character, what's the implementation independent way to
select the font?
> I don't see that a closure, as opposed to a simple function, is
> necessarily involved. An application dealing with strings, as opposed
> to (vector character), doesn't require a closure, it simply requires a
> character-set translation.
If a single string-char can reference more than one font, the
translation function must return two values (index and font) and either
has to be a closure, or accept a font-sequence as an argument.
> ... An "implementation
> dependent" function, as near as I can tell, will be "dependent" on the
> particular CL implementation of characters, but cannot be "dependent" on
> a particular X server or font set. That *might* give you a good enough
> handle to determine what the local character set is, but as far as I can
> tell it doesn't give you *any* clue to what the character sets employed
> by the particular fonts are. I don't know of any way to hide/solve this
> problem, except by mandating that CLX will only work with fonts with
> particular characteristics.
How can code be portable when the only standard you assume is CLX.
Why can't I assume that X fonts will conform to other standards like
ASCII and the ISO character set. In addition to coping with random
char-code orderings, must CLX also cope with random font glyph
orderings? Surely the C Xlib interface doesn't require these
complexities, why should the Lisp interface?
Since char-codes don't always match a standard font glyph ordering
(i.e. ISO) an implementation dependent translation function is needed.
Since some characters aren't printed (i.e. #\newline #\tab), the
translation function needs to escape back to a higher level, by
returning NIL.
Since a single font may not have all the glyphs needed for a lisp's
character set, the translation function needs to be a function of a
character and font-sequence, returning an index and font. Once you've
gone this far, why limit the translation function to string-chars when
its easy to handle full character objects.
Since 80% of the graphics activity of most applications is in writing
text, it would be nice if CLX could do it efficiently. Thats why I
suggested that there be a single in-line translation function to
eliminate the multiple-valued call/return for every character.
> It sure would be nice if we could agree on how to
> display multi-fonted text in CLX, rather than making every toolkit
> re-invent it.
>
> I'm no longer convinced that characters will necessarily be the only
> "source" for text output. This doesn't preclude agreeing on a
> character-translation interface, but it can argue against characters
> being the only interface.
Please give an example where a sequence of integers is better than
a string of characters.
When it comes to non-character fonts (like math symbols or icons) it
seems to me that its just as easy to specify "the font glyph
corresponding to character #\X" (i.e. character objects) as it is to
specify font-index 88 (i.e. integers).
> How many non-lispm CL implementations actually have a non-zero
> char-font-limit? Does anyone really agree on the use of font
> attributes? How can one write portable code in this environment, except
> by avoiding character objects?
With more standards. Isn't that what the CL-WINDOWS mailing list is
for?
Perhaps its too much to ask that level 2 code above CLX be completely
portable. If the next level is going to have a file full of
implementation dependent functions that must be translated, then maybe
all this character translation stuff belongs there, rather than CLX
(i.e. get rid of the transform functions in CLX). If this is the case,
can we at least restrict text-extents, draw-glyphs, etc. to vectors,
instead of sequences? I can't see needing to use lists of characters,
and SVREF is a little faster than ELT.
One way to ensure that nobody programs using only the CLX interface is
to make it impossible to display a string of text (this is the situation
with your last proposal). I hope that a level 2 proposal can be agreed
upon quickly.
∂19-Jun-87 0325 RWK@YUKON.SCRC.Symbolics.COM Re: more concrete font proposal
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 19 Jun 87 03:24:20 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 227065; Fri 19-Jun-87 06:21:37 EDT
Date: Fri, 19 Jun 87 06:21 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: more concrete font proposal
To: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2760014046-3641752@SI>
Message-ID: <870619062117.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 18 Jun 87 09:34:06 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
> Date: Wed, 17 Jun 87 15:57 EDT
> From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
> Subject: Re: more concrete font proposal
> If I write
> a toolkit on top of CLX, it can't be portable, because all the places
> that use CLX functions taking transform arguments will have to be
> modified (what's the right thing to do when the transform function
> returns NIL?).
>
> I don't understand this at all, and certainly not if the "CLX functions"
> you think have to be modified are things like draw-glyphs. Perhaps you
> could give a concrete example?
Perhaps I'm trying to solve a nonexistent problem. I got the impression
from Moon and Kerns that its probable that a lisp's character set
couldn't be represented with a single font. For example, #\alpha would
be in a different font from #\a. If a transform function returns NIL on
the #\alpha character, what's the implementation independent way to
select the font?
Let me explain this a little bit.
In our system, additional character sets can be loaded at any time.
For example, I could load Japanese, or Hebrew, or Cyrillic, and
create character objects in those character sets.
This has several consequences that are relevant to this discussion.
1) CHAR-CODE's usefulness is extremely limited. It does not
index into fonts, because the CHAR-CODE values have to be dynamically
assigned.
2) As you noted, the set of all characters cannot live in a single
font. That would require predetermination of all possible characters.
3) As I've noted in earlier messages, a given character must be translated
into a index into a font, not just an index. For some systems, this
translation could be CHAR-CODE and a constant font, but not for all.
There's a bit more complexity here besides multiple character-sets,
as well. The choice of font is not only determined by the character-set,
but also by what we call the character-style. A character style is
a structured object, which is subject to defaulting of NIL components
from a default with per-stream dynamic extent. A "normal" character
has NIL.NIL.NIL style, which means it takes its defaults from the
stream's current default. This default can be bound; this is one
common way of doing bold-faced output. I.e. you can do
(WITH-CHARACTER-STYLE ('(NIL :BOLD NIL) *STANDARD-OUTPUT*)
(PRINT CODE *STANDARD-OUTPUT*))
to print bold-faced Lisp forms. The characters didn't change, but
the choice of fonts did. Yet characters in a string CAN specify
boldness, typestyle (which we call family) or size, on a character
by character basis. If these properties are not specified, they
come from the default. So you can take a string with an italicized
word, and display it at different sizes, or at different typefaces.
I've explained somewhat more of this than is actually relevant here,
so that I can make it a bit clearer how it affects what we need from
CLX.
4) A given STRING-CHAR can (depending on context from the stream)
turn into one of several fonts.
5) The choice of fonts cannot be determined independent of the
context. This is one reason we cannot do character interpretation
at the raw CLX level; we need the context from the higher-level
(i.e. the stream). This can be imported from the higher level
as a closure to do translation; that would be no problem for us.
I guess it's moot whether to consider the function that calls that
function to be at the CLX level or the higher level. Personally
I'd consider it to be at the higher level, because the boundary
line is a bit clearer if you say "anything dealing with characters
is at the next level up". But that's just a convenient place to
draw an arbitrary line. Sort of like a river in geography, or
a state boundary in drawing timezone boundaries.
6) A character and a stream completely determine the choice of font and
the index into the font.
The character supplies the style, the character-set, and the index into
the character-set. Usually, but not necessarily, the index into the
character-set is the index into the font. The style is defaulted
against the stream's default. The font is found by doing a 3-way lookup
on the character-set, the defaulted style, and the stream's output
device (i.e. the model that describes what's on the other end of the X
connection).
7) There is never a need (or opportunity) to separately specify a font.
8) We have no use whatsoever for integers to represent "fonts". CL was
never clear on whether "fonts" were for implementing character-sets or
for character-styles, anyway. So we just set CHAR-FONT-LIMIT to 1,
like everybody else.
> I don't see that a closure, as opposed to a simple function, is
> necessarily involved. An application dealing with strings, as opposed
> to (vector character),
I get confused, because there is a proposal on the floor (from the
Japanese contingent) for calling what you're calling (VECTOR CHARACTER)
STRING. What you're calling STRING would be called INTERNAL-THIN-STRING.
What you're calling STRING-CHAR would be called INTERNAL-THIN-CHAR.
This is more than just a name change; the intent is that any application
should be able to deal with what you're calling (VECTOR CHARACTER).
(Ignore the BITS field).
doesn't require a closure, it simply requires a
> character-set translation.
If a single string-char can reference more than one font, the
translation function must return two values (index and font) and either
has to be a closure, or accept a font-sequence as an argument.
This is true in our implementation. A font-sequence wouldn't be
any help, there's no ordering of character-styles. However, a
closure is no problem for us.
> ... An "implementation
> dependent" function, as near as I can tell, will be "dependent" on the
> particular CL implementation of characters, but cannot be "dependent" on
> a particular X server or font set. That *might* give you a good enough
> handle to determine what the local character set is, but as far as I can
> tell it doesn't give you *any* clue to what the character sets employed
> by the particular fonts are. I don't know of any way to hide/solve this
> problem, except by mandating that CLX will only work with fonts with
> particular characteristics.
How can code be portable when the only standard you assume is CLX.
Why can't I assume that X fonts will conform to other standards like
ASCII and the ISO character set.
Because they don't all so conform. The fonts you have to work with
are the fonts that the server has. But you can HOPE for it; you
just need a way to find out about it.
In addition to coping with random
char-code orderings, must CLX also cope with random font glyph
orderings?
Surely they're not random. Surely they implement SOME standard.
Unfortunately, X doesn't define or recommend any property on a font that
says just what standard it implements, so I don't see any way to
automatically choose an appropriate translation function. Just assuming
ASCII or ISO isn't good enough; if I have a Symbolics 3650 and a Fujitsu
something-or-other, and they both support JIS Level 2, using fonts named
JIS12, JIS16, JIS24, or JIS48 on the 3650 and fonts named Japanese10,
Japanese20, and Japanese 30 on the Fujitsu system. I can set it up
manually, of course, but with a bit more information about the font I
could figure it out automatically, without a priori knowing what a
Fujitsu is.
Similarly, talking to a server that only has fonts implementing EBCDIC,
I can choose a translator that translates to EBCDIC, if I can know about
that, but if I later figure out how to define an ASCII font, I'd like to
be able to switch to using that. (Even better would be a font that implements
the entire Lispm standard character-set).
(But what do we do when a server has no font that implements a given
character? Signal a specific condition, and substitute "#" if the
condition isn't handled? Signal a specific error?)
Surely the C Xlib interface doesn't require these
complexities, why should the Lisp interface?
How many C clients do you know that deal with multiple character-sets?
That allocate the character-indexes dynamically? That deal with
characters as first-class objects?
Since char-codes don't always match a standard font glyph ordering
(i.e. ISO) an implementation dependent translation function is needed.
Since some characters aren't printed (i.e. #\newline #\tab), the
translation function needs to escape back to a higher level, by
returning NIL.
Since a single font may not have all the glyphs needed for a lisp's
character set, the translation function needs to be a function of a
character and font-sequence, returning an index and font. Once you've
gone this far, why limit the translation function to string-chars when
its easy to handle full character objects.
Agreed.
By the way, I'm curious as to what you think this "font-sequence" is
for. Is it indexed by position of the character in the string, or by
the CHAR-FONT?
Does anyone actually use CHAR-FONT? If so, can they explain how they
use it? Are the indexes global? Do they mean a character is a different
character (in the sense of STRING-EQUAL)? Do you use them for multiple
languages, or just for different presentation of English characters?
Since 80% of the graphics activity of most applications is in writing
text, it would be nice if CLX could do it efficiently. Thats why I
suggested that there be a single in-line translation function to
eliminate the multiple-valued call/return for every character.
[I can't find where you proposed this, to compare our views].
I'd like to see something like this:
(defun make-translate-string (default-style device)
(labels ((translate-string (font-change string string-start string-end)
;; This is the actual translator function
(DECLARE (TYPE FUNCTION FONT-CHANGE)
(TYPE STRING STRING)
(TYPE INTEGER STRING-START)
(TYPE INTEGER STRING-END))
(do ((i string-start (1+ i))
(char) (char-font) (char-index)
(current-font)
(buffer) (buffer-start) (buffer-end)
(buffer-pointer nil (1+ buffer-pointer)))
((= i string-end))
(setf char (aref string i))
(multiple-value-setq (char-font char-index)
(lookup-font-and-index char device default-style))
;; Handle the exceptional cases.
(unless (and (eql current-font char-font)
(not (= buffer-start buffer-end)))
;; New font; tell the caller about the new font, and how
;; much of the buffer we've used. He'll give us back a
;; new buffer, of the right size for this font.
(multiple-value-setq (buffer buffer-start buffer-end)
(funcall font-change char-font buffer-pointer))
(setq current-font char-font)
(setq buffer-pointer buffer-start))
;; Translate one character
(setf (aref buffer buffer-pointer) char-index))))
#'translate-string))
The reason I made the translation function call back the caller rather
than return on exceptions is to give the caller a chance to output the
font-changes BEFORE we stick the output into the buffer.
Most implementations, in most situations, wouldn't need to close over
anything, but I illustrated how we need to close over the default style
and the device.
> It sure would be nice if we could agree on how to
> display multi-fonted text in CLX, rather than making every toolkit
> re-invent it.
>
> I'm no longer convinced that characters will necessarily be the only
> "source" for text output. This doesn't preclude agreeing on a
> character-translation interface, but it can argue against characters
> being the only interface.
Please give an example where a sequence of integers is better than
a string of characters.
When it comes to non-character fonts (like math symbols or icons) it
seems to me that its just as easy to specify "the font glyph
corresponding to character #\X" (i.e. character objects) as it is to
specify font-index 88 (i.e. integers).
What if that index doesn't correspond to a legal character?
This will frequently be the case. Why should I have to create
bunches of illegal characters just to use CLX?
If there's going to be a character interface at all, why not
have it be the character in question, instead of some standin?
Why not use the math symbol or icon itself? How does writing
#\X make anything simpler or clearer?
Also, #\X is not portable, even when you're talking about the
same font on the same server in two different client Lisps.
> How many non-lispm CL implementations actually have a non-zero
> char-font-limit?
I haven't heard of any.
Does anyone really agree on the use of font
> attributes?
I thought a while back a survey was done, and everyone pretty
much areed they were useless.
How can one write portable code in this environment, except
> by avoiding character objects?
With more standards. Isn't that what the CL-WINDOWS mailing list is
for?
Perhaps its too much to ask that level 2 code above CLX be completely
portable. If the next level is going to have a file full of
implementation dependent functions that must be translated, then maybe
all this character translation stuff belongs there, rather than CLX
(i.e. get rid of the transform functions in CLX).
I'm not clear on what kind of portability you're talking about.
Are you talking about code that implements level 2 and uses CLX,
or are you talking about code written using level 2?
I think neither the code implementing Level 1 OR Level 2 can
be portable.
Code written using Level 1 could be portable if there was a way
to find out what protocol a given font on the server side implemented.
Code written using Level 2 would be portable. But you need a
way to find out what protocol a given font on the server side
implements, in order to write Level 2.
If this is the case,
can we at least restrict text-extents, draw-glyphs, etc. to vectors,
instead of sequences?
Yes!
I can't see needing to use lists of characters,
and SVREF is a little faster than ELT.
One way to ensure that nobody programs using only the CLX interface is
to make it impossible to display a string of text (this is the situation
with your last proposal).
This sounds like a good argument for his proposal.
I hope that a level 2 proposal can be agreed
upon quickly.
How about this? This is sort of the "lowest level of Level 2", that is,
this brings the basics up to the level of characters, but does not introduce
streams.
;; I'm using the proposed definition of the STRING and STRING-CHAR types.
;;; Actually, this type is implementation dependent.
;;; NIL means to use a global default that makes sense for
;;; this implementation.
;;; Perhaps, instead, this should get merged in with a
;;; higher-level view of a gcontext?
(deftype context () `t)
;;; This needs the display, since it will be involved in determining fonts.
;;; If multiple fonts are used, ascent and descent are computed from a common
;;; baseline. font-ascent and font-descent are maximized.
(defun text-display-extents (display string &key (start 0) end context)
(declare (type display display)
(type string string)
(type context transform)
(values width ascent descent left right font-ascent font-descent direction
(or null integer))))
;;; This needs the display, since it will be involved in determining fonts.
(defun text-display-width (display string &key (start 0) end context)
(declare (type display display)
(type string string)
(type context context)
(values integer (or null integer))))
;;; May side-effect on gcontext-font.
(defun display-character (drawable gcontext x y character &key width context)
(declare (type drawable drawable)
(type gcontext gcontext)
(type string-char character)
(type integer (x y index))
(type context context)
(type (or null integer) width)))
;;; May side-effect on gcontext-font.
(defun display-string (drawable gcontext x y string
&key (start 0) end width context)
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type (or null integer) end width)
(type context context)
(values (or null integer))))
(defun display-image-character (drawable gcontext x y character &key width context)
(declare (type drawable drawable)
(type string-char character)
(type gcontext gcontext)
(type context context)
(type integer (x y))
(type (or null integer) width)))
(defun display-image-string (drawable gcontext x y string
&key (start 0) end context width)
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type context context)
(type sequence sequence)
(type (or null integer) end width)
(values (or null integer))))
;;; [It's late, so I didn't worry about the stuff below. Whatever the lower-level
;;; interface does, I would propose a DISPLAY-TEXT, that works on STRING's, takes
;;; no fonts, and calls DRAW-TEXT or DRAW-TEXT16 as needed. --RWK]
;; Note: I haven't figured out what to do with draw-text (and draw-text16). It
;; may be that their existing definitions aren't really very useful. It may be
;; better to provide a function that takes a transform of the form:
;; (function t (or null integer) (or null font) (or null integer))
;; where the first value is the index, the second is optionally a change in
;; font, and the third is optionally a delta in x coordinate.
∂19-Jun-87 0339 RWK@YUKON.SCRC.Symbolics.COM Re: more concrete font proposal
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 19 Jun 87 03:38:52 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 227069; Fri 19-Jun-87 06:38:28 EDT
Date: Fri, 19 Jun 87 06:38 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: more concrete font proposal
To: Seth Steinberg <sas@bfly-vax.bbn.com>
cc: cl-windows@sail.stanford.edu
In-Reply-To: The message of 18 Jun 87 08:43 EDT from Seth Steinberg <sas@bfly-vax.bbn.com>
Message-ID: <870619063826.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 18 Jun 87 08:43 EDT
From: Seth Steinberg <sas@bfly-vax.bbn.com>
Mr. Scheifler has raised a valid point and I believe partially answered
it:
> I don't see how this has a prayer of working. An "implementation
> dependent" function, as near as I can tell, will be "dependent" on the
> particular CL implementation of characters, but cannot be "dependent" on
> a particular X server or font set. That *might* give you a good enough
> handle to determine what the local character set is, but as far as I can
> tell it doesn't give you *any* clue to what the character sets employed
> by the particular fonts are. I don't know of any way to hide/solve this
> problem, except by mandating that CLX will only work with fonts with
> particular characteristics.
>
> ... Does anyone really agree on the use of font attributes? ...
Since fonts are used for all sorts of things, not just displaying
ASCII, it might be a good idea to recognize this fact and have some
kind of "font attribute" which tells how well the font (or font set,
when necessary) handles displaying ASCII (e.g. :alphanumeric :printing
:national <xxx> (as opposed to ASCII which is American) and so on).
I'll assume that other parties can concentrate on how to display Kanji,
or Hindi, or Space War.
I guess great minds slide down the same gutter.
One problem I'm not sure how to deal with is fonts that implement a superset
of some standard set. For example, there are many supersets of ASCII.
Perhaps if the font-type were a list of a standard plus extensions?
I.e. (:ASCII :SYMBOLICS) or (:JIS :LEVEL-2 :NIS-EXTRA-KANJI)
Since there's two chronologically different versions of JIS level 2,
with a few Kanji moved around and substituted, etc, this would allow
them to be distinguished.
It would be real nice if the windows standard provided some system
independent means of displaying the characters in the Common Lisp
"standard character set" as described in section 2.2 of Steele's Common
Lisp book. Ah, life was some much simpler in the good old days:
Perhaps the windows standard (X, not CLX) could specify that at least
one font must support ASCII? Perhaps even specify fixed-width, for
things that need that. Even give the font a standard name, to make it
easier to find.
∂24-Jun-87 0723 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: more concrete font proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jun 87 07:23:12 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Jun 87 10:22-EDT
Date: Wed, 24 Jun 87 10:22 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2760014046-3641752@SI>
Message-ID: <870624102240.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 18 Jun 87 09:34:06 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
How can code be portable when the only standard you assume is CLX.
Why can't I assume that X fonts will conform to other standards like
ASCII and the ISO character set.
It is very desirable to have X fonts conform to other standards, but the
problem is the "s" on the end of "standards". There is no such thing as
"the ISO character set". There are currently four ISO Latin character
sets. In the beta release of X11, we've incorporated these, plus
Katakana, Arabic, Cryllic, Greek, Hebrew, and a few non-language
character sets into the keyboard symbol description set; others will
undoubtedly get added in the future. All of these are candidates for
inclusion in fonts. And of course, there are plenty of other font
compositions around to muddy the water. For example, TeX fonts have
their own scheme, Adobe fonts have their own scheme, Symbolics fonts
have their own scheme, etc.
It was an explicit "feature" that the X protocol doesn't mandate font
naming or indexing. There just isn't a consensus as to how it should be
done. However, this doesn't preclude a layered standard, and there are
people who have done some thinking about the problem, and hope to work
on a proposal during the next few months. Anyone interested in
contributing to this effort should feel free to contact me.
In addition to coping with random
char-code orderings, must CLX also cope with random font glyph
orderings?
They aren't "random", but I am forced to the conclusion that CLX cannot
mandate particular glyph orderings; it must be "policy-free" in this
case, with character translation provided "from above". That doesn't
preclude providing "standard translations", as long as you can agree on
what the interesting font encodings are.
Surely the C Xlib interface doesn't require these
complexities, why should the Lisp interface?
What you see in the C Xlib depends on how naive you are. The C routines
take in "char *" pointers. A naive person will view that as equivalent
to a CL string, with an implicit char-code transform. A more rational
view is that "char" is simply (unsigned-byte 8), with the transformation
already applied before calling Xlib. The strict equivalent in CLX would
be to only accept (vector (unsigned-byte 8)), but I find the idea of
accepting a transform more appealing.
Since char-codes don't always match a standard font glyph ordering
(i.e. ISO) an implementation dependent translation function is needed.
I really don't see an acceptable way for CLX to "know" how to do the
translation.
Since a single font may not have all the glyphs needed for a lisp's
character set, the translation function needs to be a function of a
character and font-sequence, returning an index and font.
This isn't strictly necessary. Another way is to have the translation
function return nil when the font changes, and so avoid multiple values.
Once you've
gone this far, why limit the translation function to string-chars when
its easy to handle full character objects.
Indeed, why limit to characters, rather than arbitrary objects?
Since 80% of the graphics activity of most applications is in writing
text, it would be nice if CLX could do it efficiently.
Agreed. In fact, if you want to match current hardware, which can draw
more than 20,000 characters per second, then you've got less than 50
microseconds per character, meaning you need to do it *very*
efficiently.
Thats why I
suggested that there be a single in-line translation function to
eliminate the multiple-valued call/return for every character.
I'll agree eliminating multiple-values in the normal case is probably
important. I disagree that there has to be a single in-line function.
There can be a general transform, and if people can agree on a particular
instance of such a transform, then that instance can be optimized:
(defun draw-standard-string (drawable gcontext x y string
&key (start 0) end width)
;; equivalent to draw-glyphs with :transform #'standard-string-transform,
;; and can be implemented that way if an implementation-specific
;; optimization is not otherwise provided
)
The point is that by providing a general base interface, you gain
portability, without precluding system-dependent optimizations. Perhaps
all you really want is to also define draw-standard-string and
standard-string-transform as part of CLX. I won't complain, but I think
agreeing on any definition beyond "CL standard character set to ISO
Latin 1" is going to be hard.
> I'm no longer convinced that characters will necessarily be the only
> "source" for text output. This doesn't preclude agreeing on a
> character-translation interface, but it can argue against characters
> being the only interface.
Please give an example where a sequence of integers is better than
a string of characters.
For example, an application that wants high-speed redisplay, and is
willing to do the character translation once up front, rather than on
every redisplay. Or (I hate to keep harping on this) a Kanji
application that must use integers because there isn't a guaranteed
portable char-chode-limit of 65536.
∂24-Jun-87 0844 @EDDIE.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU Re: more concrete font proposal
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jun 87 08:43:40 PDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
id <AA01833@EDDIE.MIT.EDU>; Wed, 24 Jun 87 11:36:13 EDT
Date: Wed, 24 Jun 87 11:37 EDT
From: Robert Scheifler <@EDDIE.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM, Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
Cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870619062117.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-Id: <870624113730.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Fri, 19 Jun 87 06:21 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Unfortunately, X doesn't define or recommend any property on a font that
says just what standard it implements, so I don't see any way to
automatically choose an appropriate translation function.
This is in fact one possibility that is being considered inclusion in a
layered standard.
(defun make-translate-string (default-style device)
(labels ((translate-string (font-change string string-start string-end)
;; This is the actual translator function
(DECLARE (TYPE FUNCTION FONT-CHANGE)
(TYPE STRING STRING)
(TYPE INTEGER STRING-START)
(TYPE INTEGER STRING-END))
(do ((i string-start (1+ i))
(char) (char-font) (char-index)
(current-font)
(buffer) (buffer-start) (buffer-end)
(buffer-pointer nil (1+ buffer-pointer)))
((= i string-end))
(setf char (aref string i))
(multiple-value-setq (char-font char-index)
(lookup-font-and-index char device default-style))
;; Handle the exceptional cases.
(unless (and (eql current-font char-font)
(not (= buffer-start buffer-end)))
;; New font; tell the caller about the new font, and how
;; much of the buffer we've used. He'll give us back a
;; new buffer, of the right size for this font.
(multiple-value-setq (buffer buffer-start buffer-end)
(funcall font-change char-font buffer-pointer))
(setq current-font char-font)
(setq buffer-pointer buffer-start))
;; Translate one character
(setf (aref buffer buffer-pointer) char-index))))
#'translate-string))
The reason I made the translation function call back the caller rather
than return on exceptions is to give the caller a chance to output the
font-changes BEFORE we stick the output into the buffer.
This would seem to *require* a closure for font-change. If closure
creation or invocation results in consing in typical CL implementations,
this won't be a very desirable interface. Also, exposing an internal
structure (the buffer) to unrestricted use in "user code" seems
undesirable unless it is critical to performance. Also, the comment
about the "right" buffer size is somewhat suspect. First, the X
protocol allows 8-bit indexes for 16-bit fonts; your interface would
seem to always require 16-bit indexes, e.g., even when the effective
character set is Latin 1 but the font happens to have all of JIS. Also,
the standard X byte stream is based on 8-bit bytes, with 16-bit font
indexes (as opposed to first-byte/second-byte) transmitted most
significant byte first. Your interface would seem to require an extra
pass over the buffer to byte-swap on some systems, and would also seem
to require either the ability to displace 16-bit arrays onto 8-bit
arrays (which CLtL says "is an error") or an extra buffer and a copy.
;; I'm using the proposed definition of the STRING and STRING-CHAR types.
;;; Actually, this type is implementation dependent.
;;; NIL means to use a global default that makes sense for
;;; this implementation.
What is the scope of an "implementation"? Are there assumptions about
character sets and fonts used?
;;; Perhaps, instead, this should get merged in with a
;;; higher-level view of a gcontext?
Actually adding a component to the CLX-level gcontext might be
reasonable.
(deftype context () `t)
Is translate-string above an example of a context? If not, what is
the relationship, and what are the operations on a context?
;;; This needs the display, since it will be involved in determining fonts.
;;; If multiple fonts are used, ascent and descent are computed from a common
;;; baseline. font-ascent and font-descent are maximized.
(defun text-display-extents (display string &key (start 0) end context)
(declare (type display display)
(type string string)
(type context transform)
(values width ascent descent left right font-ascent font-descent direction
(or null integer))))
If translate-string is an example of a context, then the implementation
of this when the metrics are local involves a somewhat useless storing
and fetching of indexes into an intermediate buffer, but I suppose the
output functions are the critical ones for performance.
If translate-string is an example of a context, then I don't see why
text-display-extents and the other functions you listed care what the
type of the string argument is; presumably it is simply up to the caller
(of text-display-extents) to provide an argument that matches the type
expected for the second argument to transform. It doesn't even need to
be vector, much less have a particular element-type.
;;; [It's late, so I didn't worry about the stuff below. Whatever the lower-level
;;; interface does, I would propose a DISPLAY-TEXT, that works on STRING's, takes
;;; no fonts, and calls DRAW-TEXT or DRAW-TEXT16 as needed. --RWK]
Your proposed interface essentially subsumes draw-text; the distinction between
draw-glyphs and draw-text was one of allowing embedded font-shifts.
∂24-Jun-87 1056 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU CLX beta changes
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jun 87 10:55:59 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Jun 87 13:45-EDT
Date: Wed, 24 Jun 87 13:44 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX beta changes
To: cl-windows@sail.stanford.edu
Message-ID: <870624134459.4.RWS@KILLINGTON.LCS.MIT.EDU>
The following reflect changes between the Alpha-Update and the Beta
protocol documents. The Beta protocol document, and a revisions file,
are available via anonymous ftp to zap.mit.edu; I will mail them to
anyone who wants them but doesn't have ftp access.
Things that get removed:
device from screen defstruct
display-keyboard
display-pointer
property-error
keyboard-mapping and setf (but name reused with different semantics below)
Things that get altered:
in modifier-key, :caps-lock renamed to :lock
in get-property, nil is returned for the type when the protocol returns None
in :exposure and :graphics-exposure events,
(boolean last-p) is changed to (integer count)
The rest is new:
(defun display-keycode-range (display)
(declare (type display display)
(values min max)))
;; Should this signal device-busy like the pointer-mapping setf, and return a
;; boolean instead (true for success)? Alternatively, should the
;; pointer-mapping setf be changed to set-pointer-mapping with a (member
;; :success :busy) result?
(defun set-modifier-mapping (display &key shift lock control mod1 mod2 mod3 mod4 mod5)
;; Setf ought to allow multiple values.
(declare (type display display)
(type (or null integer) lock)
;; (list integer) is really a list of length 2
(type (or null integer (list integer)) shift control
mod1 mod2 mod3 mod4 mod5)
(values (member :success :busy :failed))))
(defun modifier-mapping (display)
;; each value is either nil, a single integer, or a list of two integers
(declare (type display display)
(values shift lock control mod1 mod2 mod3 mod4 mod5)))
;; Either we will want lots of defconstants for well-known values, or perhaps
;; an integer-to-keyword translation function for well-known values.
(deftype keysym () 'integer)
(defun change-keyboard-mapping (display keysyms &key (start1 0) end1 (start2 start1))
;; start1/end1 give subrange of keysyms
;; start2 is the first-keycode to store at
;; are there better argument names?
(declare (type display display)
(type integer start1 start2)
(type (or null integer) end1)
(type (array keysym 2))))
(defun keyboard-mapping (display &key start end)
(declare (type display display)
(type (or null integer) start end)
(values (array keysym 2))))
(declare-event :mapping-notify
((member :modifier :keyboard :pointer) request)
(integer start count)) ; transform count to end instead?
∂24-Jun-87 1236 RWK@YUKON.SCRC.Symbolics.COM Re: more concrete font proposal
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jun 87 12:36:11 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 229633; Wed 24-Jun-87 15:34:21 EDT
Date: Wed, 24 Jun 87 15:34 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: more concrete font proposal
To: Robert Scheifler <@EDDIE.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU>
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624113730.2.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Wed, 24 Jun 87 11:37 EDT
From: Robert Scheifler <@EDDIE.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU>
Date: Fri, 19 Jun 87 06:21 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Unfortunately, X doesn't define or recommend any property on a font that
says just what standard it implements, so I don't see any way to
automatically choose an appropriate translation function.
This is in fact one possibility that is being considered inclusion in a
layered standard.
Sounds good.
(defun make-translate-string (default-style device)
(labels ((translate-string (font-change string string-start string-end)
;; This is the actual translator function
(DECLARE (TYPE FUNCTION FONT-CHANGE)
(TYPE STRING STRING)
(TYPE INTEGER STRING-START)
(TYPE INTEGER STRING-END))
(do ((i string-start (1+ i))
(char) (char-font) (char-index)
(current-font)
(buffer) (buffer-start) (buffer-end)
(buffer-pointer nil (1+ buffer-pointer)))
((= i string-end))
(setf char (aref string i))
(multiple-value-setq (char-font char-index)
(lookup-font-and-index char device default-style))
;; Handle the exceptional cases.
(unless (and (eql current-font char-font)
(not (= buffer-start buffer-end)))
;; New font; tell the caller about the new font, and how
;; much of the buffer we've used. He'll give us back a
;; new buffer, of the right size for this font.
(multiple-value-setq (buffer buffer-start buffer-end)
(funcall font-change char-font buffer-pointer))
(setq current-font char-font)
(setq buffer-pointer buffer-start))
;; Translate one character
(setf (aref buffer buffer-pointer) char-index))))
#'translate-string))
The reason I made the translation function call back the caller rather
than return on exceptions is to give the caller a chance to output the
font-changes BEFORE we stick the output into the buffer.
This would seem to *require* a closure for font-change. If closure
creation or invocation results in consing in typical CL implementations,
this won't be a very desirable interface.
It only requires a closure in implementations which to close over the
default style or device. And if they only need to close over the device,
then this closure only need be consed once per device.
This example wasn't for an arbitrary implementation; I expect
most implementations will not need to cons closures for this
at all, or only once per device. In our case, the closure
wouldn't have to be consed. I simplified the example a bit;
we don't have to call LOOKUP-FONT-AND-INDEX for every
character, either. In fact, under this scheme, we would only
have to do function calls on font changes and buffer boundaries.
Also, exposing an internal
structure (the buffer) to unrestricted use in "user code" seems
undesirable unless it is critical to performance.
I believe it is critical to performance. As I noted above,
we don't have to have function calls except on font-shift
or buffer boundaries. I don't think there's any other way
you can achieve this level of efficiency without giving the
translation function the buffer. An implementation can choose
to give out a buffer that is an indirect-array to a portion of
his real buffer if it wishes, or even a dummy buffer that it
then copies into the real buffer.
Even if an implementation has AREF and ASET be as slow as
function calls, it is probably faster to do it this way,
because some of the work can be done just once per call
to the translator, or once per font-shift. You can't do
that kind of optimization when you call once per character.
Also, the comment
about the "right" buffer size is somewhat suspect. First, the X
protocol allows 8-bit indexes for 16-bit fonts; your interface would
seem to always require 16-bit indexes, e.g., even when the effective
character set is Latin 1 but the font happens to have all of JIS.
(Bleh, talk about non-standard indexing!) OK, then give the font-change
callback routine three more arguments:
(funcall font-change char-font buffer-pointer string i string-end)
so it can do prediction if it wants. Or see below.
Also,
the standard X byte stream is based on 8-bit bytes, with 16-bit font
indexes (as opposed to first-byte/second-byte) transmitted most
significant byte first. Your interface would seem to require an extra
pass over the buffer to byte-swap on some systems, and would also seem
to require either the ability to displace 16-bit arrays onto 8-bit
arrays (which CLtL says "is an error") or an extra buffer and a copy.
Whatever's appropriate on a given implementation. There's
nothing wrong with an extra buffer and a copy. This is
a high-bandwidth communications path between a translation
function and the lower level. An "extra" buffer is a small
price to pay to cut down on the number of function calls
by approximately 1/buffer-size.
Byte swapping is only an issue if you make it one; i.e. if
you displace 16-bit arrays onto 8-bit arrays. The real point
of the buffer is not to be a way to get the data directly into
the network packet, but rather to get the data from the
translation function to the transmission routine as efficiently
as possible. If it's possible in a given implementation to
optimize this to putting bytes directly into network packets,
fine, but that's not the point.
;; I'm using the proposed definition of the STRING and STRING-CHAR types.
;;; Actually, this type is implementation dependent.
;;; NIL means to use a global default that makes sense for
;;; this implementation.
What is the scope of an "implementation"? Are there assumptions about
character sets and fonts used?
I'm not sure what you're asking. I didn't know implementations had scopes.
Assumptions character sets and fonts used by whom? Where? Huh?
Stabbing in the dark, I'll try explaining some more and hoping I answer
your questions by accident. (And save one round of messages). The
purpose of the context is to provide a way for implementations to
contextually modify the interpretation of the characters. It is
essentially information that the translator function might need, to
translate from characters to fonts & indicies.
In our system, it provides the current-character-style. In an implementation
that used CHAR-FONTS, it might be an array of fonts. Probably in both
cases the context would either be a stream, or be derived from a stream.
I don't see how there could be any assumptions about character sets or
fonts, but then I don't understand the question.
;;; Perhaps, instead, this should get merged in with a
;;; higher-level view of a gcontext?
Actually adding a component to the CLX-level gcontext might be
reasonable.
Well, how does the higher level get its hands on it. If this
CONTEXT is a stream, then both how did this higher level get
its hands on the GCONTEXT, and how did the GCONTEXT get its
hands on the STREAM, which came from yet a higher level?
I'm not sure I understand the modularity of GCONTEXT's.
(deftype context () `t)
Is translate-string above an example of a context?
That wasn't my intent, but it could serve, with a translator
that just called the context as a function on its arguments.
But see below.
If not, what is
the relationship, and what are the operations on a context?
My intent was that the context is used to derive the translation
function. I didn't think that I needed to specify how it would
be derived, but I missed seeing that that just passed up the
implementation-dependence up a layer. Part of the purpose of
this layer is to be able to enable users to write
implementation-independent software on top of it. (That's why
there's a default context).
So, there are just two operations a context needs to support:
(defun get-output-translation-function (context)
(declare (type context context)
(values output-translation-function)))
;;; We forgot about translation on input! This can safely be
;;; a character-at-a-time unbuffered.
(defun get-input-translation-function (context)
(declare (type context context)
(values input-translation-function)))
;;; This needs the display, since it will be involved in determining fonts.
;;; If multiple fonts are used, ascent and descent are computed from a common
;;; baseline. font-ascent and font-descent are maximized.
(defun text-display-extents (display string &key (start 0) end context)
(declare (type display display)
(type string string)
(type context transform)
(values width ascent descent left right font-ascent font-descent direction
(or null integer))))
If translate-string is an example of a context, then the implementation
of this when the metrics are local involves a somewhat useless storing
and fetching of indexes into an intermediate buffer, but I suppose the
output functions are the critical ones for performance.
It's not useless. It's the fastest way to get data from the
translation function to the routine going to interpret the
metrics. This will be FASTER than if it didn't store into
an intermediate buffer, not SLOWER.
If translate-string is an example of a context,
Close enough to make the rest of your comment relevant...
then I don't see why
text-display-extents and the other functions you listed care what the
type of the string argument is; presumably it is simply up to the caller
(of text-display-extents) to provide an argument that matches the type
expected for the second argument to transform. It doesn't even need to
be vector, much less have a particular element-type.
This is true. It makes it harder to specify in this
specification-language, though. Do you think this is
worth including explicitly as part of the specification
for this layer?
;;; [It's late, so I didn't worry about the stuff below. Whatever the lower-level
;;; interface does, I would propose a DISPLAY-TEXT, that works on STRING's, takes
;;; no fonts, and calls DRAW-TEXT or DRAW-TEXT16 as needed. --RWK]
Your proposed interface essentially subsumes draw-text; the distinction between
draw-glyphs and draw-text was one of allowing embedded font-shifts.
Good.
∂24-Jun-87 1351 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: more concrete font proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jun 87 13:51:38 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Jun 87 16:50-EDT
Date: Wed, 24 Jun 87 16:50 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870624165008.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 24 Jun 87 15:34 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
;; New font; tell the caller about the new font, and how
;; much of the buffer we've used. He'll give us back a
;; new buffer, of the right size for this font.
(multiple-value-setq (buffer buffer-start buffer-end)
(funcall font-change char-font buffer-pointer))
The reason I made the translation function call back the caller rather
than return on exceptions is to give the caller a chance to output the
font-changes BEFORE we stick the output into the buffer.
This would seem to *require* a closure for font-change. If closure
creation or invocation results in consing in typical CL implementations,
this won't be a very desirable interface.
It only requires a closure in implementations which to close over the
default style or device. And if they only need to close over the device,
then this closure only need be consed once per device.
I'm talking about the font-change function, not the translate-string
function. As you wrote it, it somehow has to encapsulate a buffer and
other state, which sounds like a closure.
∂25-Jun-87 0813 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: more concrete font proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87 08:12:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Jun 87 11:09-EDT
Date: Thu, 25 Jun 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870625111051.5.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 24 Jun 87 15:34 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
;;; Actually, this type is implementation dependent.
;;; NIL means to use a global default that makes sense for
;;; this implementation.
What is the scope of an "implementation"? Are there assumptions about
character sets and fonts used?
I'm not sure what you're asking. I didn't know implementations had scopes.
Assumptions character sets and fonts used by whom? Where? Huh?
I was really just trying to figure out whether the default global
context had to have knowledge of "non-standard" character features of
the local CL implementation (e.g., si:char-style), and whether it also
had to have knowledge of the font encodings. That is, is it written as
part of CLX, or is it written for each (CL, CLX) pair, or can it
actually be written at all. Anyway, I think I get the picture.
;;; Perhaps, instead, this should get merged in with a
;;; higher-level view of a gcontext?
Actually adding a component to the CLX-level gcontext might be
reasonable.
Well, how does the higher level get its hands on it. If this
CONTEXT is a stream, then both how did this higher level get
its hands on the GCONTEXT, and how did the GCONTEXT get its
hands on the STREAM, which came from yet a higher level?
I'm not sure I understand the modularity of GCONTEXT's.
Mostly I'm trying to figure out how to make your mini-level "go away"
(see below), but provide necessary capability in CLX.
My intent was that the context is used to derive the translation
function.
(defun get-output-translation-function (context)
(declare (type context context)
(values output-translation-function)))
So what I had in mind was, if you think of a context as something like a
stream, then the stream will likely contain a gcontext to get its work
done, and the stream can itself compute the translation function and
either store it in the gcontext whenever it needs to change, or bind it
using with-gcontext. You can then argue about what translation function
to store when a gcontext is initially created, if one isn't specified.
If this is the essential operation on a context for output, then I don't
see why (at the CLX layer) passing in a context is any better than
passing in a translation function.
;;; We forgot about translation on input! This can safely be
;;; a character-at-a-time unbuffered.
I've been intentionally ignoring this for now, both to avoid confusion
and while awaiting beta release so that people could see the KEYSYM
stuff. The input side isn't the inverse of output (it doesn't convert a
font+index into a character), it needs to convert a KEYSYM+bits+???
into a character.
If translate-string is an example of a context,
Close enough to make the rest of your comment relevant...
then I don't see why
text-display-extents and the other functions you listed care what the
type of the string argument is; presumably it is simply up to the caller
(of text-display-extents) to provide an argument that matches the type
expected for the second argument to transform. It doesn't even need to
be vector, much less have a particular element-type.
This is true. It makes it harder to specify in this
specification-language, though. Do you think this is
worth including explicitly as part of the specification
for this layer?
I don't think it is any harder to specify. Let me try by giving a
variation on your proposal that incorporates a number of changes: it
isn't restricted to strings; it does not have contexts, just translation
functions; it eliminates the call-backs within the translator, and
eliminates the buffer limit; it allows delta-x motion by the translator;
it tries to sort out some problems with 8-bit vs. 16-bit indexing; it
allows the translator to convey width information for request chaining;
it raises various questions.
;; I would write a deftype, but it's easier to have argument names:
(defun translate-skeleton (src src-start src-end font dst dst-start)
;; dst is guaranteed to have room for (- src-end src-start) integer elements,
;; starting at dst-start; whether dst holds 8-bit or 16-bit elements depends
;; on context. font is the current font, if known. The function should
;; translate as many elements of src as possible into indexes in the current
;; font, and store them into dst. The first return value should be the src
;; index of the first untranslated element. If no further elements need to
;; be translated, the second return value should be nil. If a horizontal
;; motion is required before further translation, the second return value
;; should be the delta in x coordinate. If a font change is required for
;; further translation, the second return value should be the new font. If
;; known, the pixel width of the translated text can be returned as the third
;; value; this can allow for appending of subsequent output to the same
;; protocol request, if no overall width has been specified at the higher
;; level.
(declare (type sequence src)
(type integer src-start src-end dst-start)
(type (or null font) font)
(type vector dst)
(values integer (or null integer font) (or null integer))))
;; There is a question below of whether translate should always be required, or
;; if not, what the default should be or where it should come from. For
;; example, the default could be something that expected a string as src and
;; translated the CL standard character set to ASCII indexes, and ignored fonts
;; and bits. Or the default could expect a string but otherwise be "system
;; dependent". Or the default could be something that expected a vector of
;; integers and did no translation. Or the default could come from the
;; gcontext (but what about text-extents and text-width?).
(defun text-extents (sequence &key (start 0) end font translate)
;; If multiple fonts are involved, font-ascent and font-descent will be the
;; maximums. If multiple directions are involved, the direction will be nil.
;; Translate will always be called with a 16-bit dst buffer.
(declare (type sequence sequence)
(type (or null font gcontext) font)
(type translate translate)
(values width ascent descent left right font-ascent font-descent direction
(or null integer))))
(defun text-width (sequence &key (start 0) end font translate)
;; Translate will always be called with a 16-bit dst buffer.
(declare (type sequence sequence)
(type (or null font gcontext) font)
(type translate translate)
(values integer (or null integer))))
;; This controls the element size of the dst buffer given to translate. If
;; :default is specified, the size will be based on the current font, if known,
;; and otherwise 16 will be used. [An alternative would be to pass the buffer
;; size to translate, and allow it to return the desired size if it doesn't
;; like the current size. The problem is that the protocol doesn't allow
;; switching within a single request, so to allow switching would require
;; knowing the width of text, which isn't necessarily known. We could call
;; text-width to compute it, but perhaps that is doing too many favors?] [An
;; additional possibility is to allow an index-size of :two-byte, in which case
;; translate would be given a double-length 8-bit array, and translate would be
;; expected to store first-byte/second-byte instead of 16-bit integers.]
(deftype index-size () '(member :default 8 16))
;; In the functions below, if width is specified, it is assumed to be the total
;; pixel width of whatever string of glyphs is actually drawn. Specifying
;; width will allow for appending the output of subsequent calls to the same
;; protocol request, provided gcontext has not been modified in the interim.
;; If width is not specified, appending of subsequent output might not occur
;; (unless translate returns the width). Specifying width is simply a hint,
;; for performance.
(defun draw-glyph (drawable gcontext x y elt
&key translate width (size :default))
;; Returns true if elt is output, nil if translate refuses to output it.
;; Second result is width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type translate translate)
(type (or null integer) width)
(type index-size size)
(values boolean (or null integer))))
(defun draw-glyphs (drawable gcontext x y sequence
&key (start 0) end translate width (size :default))
;; First result is new start, if end was not reached. Second result is
;; overall width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type translate translate)
(type index-size size)
(values (or null integer) (or null integer))))
(defun draw-image-glyph (drawable gcontext x y elt
&key translate width (size :default))
;; Returns true if elt is output, nil if translate refuses to output it.
;; Second result is overall width, if known. An initial font change is
;; allowed from translate.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type translate translate)
(type (or null integer) width)
(type index-size size)
(values boolean (or null integer))))
(defun draw-image-glyphs (drawable gcontext x y sequence
&key (start 0) end width translate (size :default))
;; An initial font change is allowed from translate, but any subsequent font
;; change or horizontal motion will cause termination (because the protocol
;; doesn't support chaining). [Alternatively, font changes could be accepted
;; as long as they are accompanied with a width return value, or always
;; accept font changes and call text-width as required. However, horizontal
;; motion can't really be accepted, due to semantics.] First result is new
;; start, if end was not reached. Second result is overall width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type translate translate)
(type index-size size)
(values (or null integer) (or null integer))))
∂25-Jun-87 1028 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: more concrete font proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87 08:12:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Jun 87 11:09-EDT
Date: Thu, 25 Jun 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870625111051.5.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 24 Jun 87 15:34 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
;;; Actually, this type is implementation dependent.
;;; NIL means to use a global default that makes sense for
;;; this implementation.
What is the scope of an "implementation"? Are there assumptions about
character sets and fonts used?
I'm not sure what you're asking. I didn't know implementations had scopes.
Assumptions character sets and fonts used by whom? Where? Huh?
I was really just trying to figure out whether the default global
context had to have knowledge of "non-standard" character features of
the local CL implementation (e.g., si:char-style), and whether it also
had to have knowledge of the font encodings. That is, is it written as
part of CLX, or is it written for each (CL, CLX) pair, or can it
actually be written at all. Anyway, I think I get the picture.
;;; Perhaps, instead, this should get merged in with a
;;; higher-level view of a gcontext?
Actually adding a component to the CLX-level gcontext might be
reasonable.
Well, how does the higher level get its hands on it. If this
CONTEXT is a stream, then both how did this higher level get
its hands on the GCONTEXT, and how did the GCONTEXT get its
hands on the STREAM, which came from yet a higher level?
I'm not sure I understand the modularity of GCONTEXT's.
Mostly I'm trying to figure out how to make your mini-level "go away"
(see below), but provide necessary capability in CLX.
My intent was that the context is used to derive the translation
function.
(defun get-output-translation-function (context)
(declare (type context context)
(values output-translation-function)))
So what I had in mind was, if you think of a context as something like a
stream, then the stream will likely contain a gcontext to get its work
done, and the stream can itself compute the translation function and
either store it in the gcontext whenever it needs to change, or bind it
using with-gcontext. You can then argue about what translation function
to store when a gcontext is initially created, if one isn't specified.
If this is the essential operation on a context for output, then I don't
see why (at the CLX layer) passing in a context is any better than
passing in a translation function.
;;; We forgot about translation on input! This can safely be
;;; a character-at-a-time unbuffered.
I've been intentionally ignoring this for now, both to avoid confusion
and while awaiting beta release so that people could see the KEYSYM
stuff. The input side isn't the inverse of output (it doesn't convert a
font+index into a character), it needs to convert a KEYSYM+bits+???
into a character.
If translate-string is an example of a context,
Close enough to make the rest of your comment relevant...
then I don't see why
text-display-extents and the other functions you listed care what the
type of the string argument is; presumably it is simply up to the caller
(of text-display-extents) to provide an argument that matches the type
expected for the second argument to transform. It doesn't even need to
be vector, much less have a particular element-type.
This is true. It makes it harder to specify in this
specification-language, though. Do you think this is
worth including explicitly as part of the specification
for this layer?
I don't think it is any harder to specify. Let me try by giving a
variation on your proposal that incorporates a number of changes: it
isn't restricted to strings; it does not have contexts, just translation
functions; it eliminates the call-backs within the translator, and
eliminates the buffer limit; it allows delta-x motion by the translator;
it tries to sort out some problems with 8-bit vs. 16-bit indexing; it
allows the translator to convey width information for request chaining;
it raises various questions.
;; I would write a deftype, but it's easier to have argument names:
(defun translate-skeleton (src src-start src-end font dst dst-start)
;; dst is guaranteed to have room for (- src-end src-start) integer elements,
;; starting at dst-start; whether dst holds 8-bit or 16-bit elements depends
;; on context. font is the current font, if known. The function should
;; translate as many elements of src as possible into indexes in the current
;; font, and store them into dst. The first return value should be the src
;; index of the first untranslated element. If no further elements need to
;; be translated, the second return value should be nil. If a horizontal
;; motion is required before further translation, the second return value
;; should be the delta in x coordinate. If a font change is required for
;; further translation, the second return value should be the new font. If
;; known, the pixel width of the translated text can be returned as the third
;; value; this can allow for appending of subsequent output to the same
;; protocol request, if no overall width has been specified at the higher
;; level.
(declare (type sequence src)
(type integer src-start src-end dst-start)
(type (or null font) font)
(type vector dst)
(values integer (or null integer font) (or null integer))))
;; There is a question below of whether translate should always be required, or
;; if not, what the default should be or where it should come from. For
;; example, the default could be something that expected a string as src and
;; translated the CL standard character set to ASCII indexes, and ignored fonts
;; and bits. Or the default could expect a string but otherwise be "system
;; dependent". Or the default could be something that expected a vector of
;; integers and did no translation. Or the default could come from the
;; gcontext (but what about text-extents and text-width?).
(defun text-extents (sequence &key (start 0) end font translate)
;; If multiple fonts are involved, font-ascent and font-descent will be the
;; maximums. If multiple directions are involved, the direction will be nil.
;; Translate will always be called with a 16-bit dst buffer.
(declare (type sequence sequence)
(type (or null font gcontext) font)
(type translate translate)
(values width ascent descent left right font-ascent font-descent direction
(or null integer))))
(defun text-width (sequence &key (start 0) end font translate)
;; Translate will always be called with a 16-bit dst buffer.
(declare (type sequence sequence)
(type (or null font gcontext) font)
(type translate translate)
(values integer (or null integer))))
;; This controls the element size of the dst buffer given to translate. If
;; :default is specified, the size will be based on the current font, if known,
;; and otherwise 16 will be used. [An alternative would be to pass the buffer
;; size to translate, and allow it to return the desired size if it doesn't
;; like the current size. The problem is that the protocol doesn't allow
;; switching within a single request, so to allow switching would require
;; knowing the width of text, which isn't necessarily known. We could call
;; text-width to compute it, but perhaps that is doing too many favors?] [An
;; additional possibility is to allow an index-size of :two-byte, in which case
;; translate would be given a double-length 8-bit array, and translate would be
;; expected to store first-byte/second-byte instead of 16-bit integers.]
(deftype index-size () '(member :default 8 16))
;; In the functions below, if width is specified, it is assumed to be the total
;; pixel width of whatever string of glyphs is actually drawn. Specifying
;; width will allow for appending the output of subsequent calls to the same
;; protocol request, provided gcontext has not been modified in the interim.
;; If width is not specified, appending of subsequent output might not occur
;; (unless translate returns the width). Specifying width is simply a hint,
;; for performance.
(defun draw-glyph (drawable gcontext x y elt
&key translate width (size :default))
;; Returns true if elt is output, nil if translate refuses to output it.
;; Second result is width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type translate translate)
(type (or null integer) width)
(type index-size size)
(values boolean (or null integer))))
(defun draw-glyphs (drawable gcontext x y sequence
&key (start 0) end translate width (size :default))
;; First result is new start, if end was not reached. Second result is
;; overall width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type translate translate)
(type index-size size)
(values (or null integer) (or null integer))))
(defun draw-image-glyph (drawable gcontext x y elt
&key translate width (size :default))
;; Returns true if elt is output, nil if translate refuses to output it.
;; Second result is overall width, if known. An initial font change is
;; allowed from translate.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type translate translate)
(type (or null integer) width)
(type index-size size)
(values boolean (or null integer))))
(defun draw-image-glyphs (drawable gcontext x y sequence
&key (start 0) end width translate (size :default))
;; An initial font change is allowed from translate, but any subsequent font
;; change or horizontal motion will cause termination (because the protocol
;; doesn't support chaining). [Alternatively, font changes could be accepted
;; as long as they are accompanied with a width return value, or always
;; accept font changes and call text-width as required. However, horizontal
;; motion can't really be accepted, due to semantics.] First result is new
;; start, if end was not reached. Second result is overall width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type translate translate)
(type index-size size)
(values (or null integer) (or null integer))))
∂25-Jun-87 1143 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: more concrete font proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87 08:12:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Jun 87 11:09-EDT
Date: Thu, 25 Jun 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870625111051.5.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 24 Jun 87 15:34 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
;;; Actually, this type is implementation dependent.
;;; NIL means to use a global default that makes sense for
;;; this implementation.
What is the scope of an "implementation"? Are there assumptions about
character sets and fonts used?
I'm not sure what you're asking. I didn't know implementations had scopes.
Assumptions character sets and fonts used by whom? Where? Huh?
I was really just trying to figure out whether the default global
context had to have knowledge of "non-standard" character features of
the local CL implementation (e.g., si:char-style), and whether it also
had to have knowledge of the font encodings. That is, is it written as
part of CLX, or is it written for each (CL, CLX) pair, or can it
actually be written at all. Anyway, I think I get the picture.
;;; Perhaps, instead, this should get merged in with a
;;; higher-level view of a gcontext?
Actually adding a component to the CLX-level gcontext might be
reasonable.
Well, how does the higher level get its hands on it. If this
CONTEXT is a stream, then both how did this higher level get
its hands on the GCONTEXT, and how did the GCONTEXT get its
hands on the STREAM, which came from yet a higher level?
I'm not sure I understand the modularity of GCONTEXT's.
Mostly I'm trying to figure out how to make your mini-level "go away"
(see below), but provide necessary capability in CLX.
My intent was that the context is used to derive the translation
function.
(defun get-output-translation-function (context)
(declare (type context context)
(values output-translation-function)))
So what I had in mind was, if you think of a context as something like a
stream, then the stream will likely contain a gcontext to get its work
done, and the stream can itself compute the translation function and
either store it in the gcontext whenever it needs to change, or bind it
using with-gcontext. You can then argue about what translation function
to store when a gcontext is initially created, if one isn't specified.
If this is the essential operation on a context for output, then I don't
see why (at the CLX layer) passing in a context is any better than
passing in a translation function.
;;; We forgot about translation on input! This can safely be
;;; a character-at-a-time unbuffered.
I've been intentionally ignoring this for now, both to avoid confusion
and while awaiting beta release so that people could see the KEYSYM
stuff. The input side isn't the inverse of output (it doesn't convert a
font+index into a character), it needs to convert a KEYSYM+bits+???
into a character.
If translate-string is an example of a context,
Close enough to make the rest of your comment relevant...
then I don't see why
text-display-extents and the other functions you listed care what the
type of the string argument is; presumably it is simply up to the caller
(of text-display-extents) to provide an argument that matches the type
expected for the second argument to transform. It doesn't even need to
be vector, much less have a particular element-type.
This is true. It makes it harder to specify in this
specification-language, though. Do you think this is
worth including explicitly as part of the specification
for this layer?
I don't think it is any harder to specify. Let me try by giving a
variation on your proposal that incorporates a number of changes: it
isn't restricted to strings; it does not have contexts, just translation
functions; it eliminates the call-backs within the translator, and
eliminates the buffer limit; it allows delta-x motion by the translator;
it tries to sort out some problems with 8-bit vs. 16-bit indexing; it
allows the translator to convey width information for request chaining;
it raises various questions.
;; I would write a deftype, but it's easier to have argument names:
(defun translate-skeleton (src src-start src-end font dst dst-start)
;; dst is guaranteed to have room for (- src-end src-start) integer elements,
;; starting at dst-start; whether dst holds 8-bit or 16-bit elements depends
;; on context. font is the current font, if known. The function should
;; translate as many elements of src as possible into indexes in the current
;; font, and store them into dst. The first return value should be the src
;; index of the first untranslated element. If no further elements need to
;; be translated, the second return value should be nil. If a horizontal
;; motion is required before further translation, the second return value
;; should be the delta in x coordinate. If a font change is required for
;; further translation, the second return value should be the new font. If
;; known, the pixel width of the translated text can be returned as the third
;; value; this can allow for appending of subsequent output to the same
;; protocol request, if no overall width has been specified at the higher
;; level.
(declare (type sequence src)
(type integer src-start src-end dst-start)
(type (or null font) font)
(type vector dst)
(values integer (or null integer font) (or null integer))))
;; There is a question below of whether translate should always be required, or
;; if not, what the default should be or where it should come from. For
;; example, the default could be something that expected a string as src and
;; translated the CL standard character set to ASCII indexes, and ignored fonts
;; and bits. Or the default could expect a string but otherwise be "system
;; dependent". Or the default could be something that expected a vector of
;; integers and did no translation. Or the default could come from the
;; gcontext (but what about text-extents and text-width?).
(defun text-extents (sequence &key (start 0) end font translate)
;; If multiple fonts are involved, font-ascent and font-descent will be the
;; maximums. If multiple directions are involved, the direction will be nil.
;; Translate will always be called with a 16-bit dst buffer.
(declare (type sequence sequence)
(type (or null font gcontext) font)
(type translate translate)
(values width ascent descent left right font-ascent font-descent direction
(or null integer))))
(defun text-width (sequence &key (start 0) end font translate)
;; Translate will always be called with a 16-bit dst buffer.
(declare (type sequence sequence)
(type (or null font gcontext) font)
(type translate translate)
(values integer (or null integer))))
;; This controls the element size of the dst buffer given to translate. If
;; :default is specified, the size will be based on the current font, if known,
;; and otherwise 16 will be used. [An alternative would be to pass the buffer
;; size to translate, and allow it to return the desired size if it doesn't
;; like the current size. The problem is that the protocol doesn't allow
;; switching within a single request, so to allow switching would require
;; knowing the width of text, which isn't necessarily known. We could call
;; text-width to compute it, but perhaps that is doing too many favors?] [An
;; additional possibility is to allow an index-size of :two-byte, in which case
;; translate would be given a double-length 8-bit array, and translate would be
;; expected to store first-byte/second-byte instead of 16-bit integers.]
(deftype index-size () '(member :default 8 16))
;; In the functions below, if width is specified, it is assumed to be the total
;; pixel width of whatever string of glyphs is actually drawn. Specifying
;; width will allow for appending the output of subsequent calls to the same
;; protocol request, provided gcontext has not been modified in the interim.
;; If width is not specified, appending of subsequent output might not occur
;; (unless translate returns the width). Specifying width is simply a hint,
;; for performance.
(defun draw-glyph (drawable gcontext x y elt
&key translate width (size :default))
;; Returns true if elt is output, nil if translate refuses to output it.
;; Second result is width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type translate translate)
(type (or null integer) width)
(type index-size size)
(values boolean (or null integer))))
(defun draw-glyphs (drawable gcontext x y sequence
&key (start 0) end translate width (size :default))
;; First result is new start, if end was not reached. Second result is
;; overall width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type translate translate)
(type index-size size)
(values (or null integer) (or null integer))))
(defun draw-image-glyph (drawable gcontext x y elt
&key translate width (size :default))
;; Returns true if elt is output, nil if translate refuses to output it.
;; Second result is overall width, if known. An initial font change is
;; allowed from translate.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type translate translate)
(type (or null integer) width)
(type index-size size)
(values boolean (or null integer))))
(defun draw-image-glyphs (drawable gcontext x y sequence
&key (start 0) end width translate (size :default))
;; An initial font change is allowed from translate, but any subsequent font
;; change or horizontal motion will cause termination (because the protocol
;; doesn't support chaining). [Alternatively, font changes could be accepted
;; as long as they are accompanied with a width return value, or always
;; accept font changes and call text-width as required. However, horizontal
;; motion can't really be accepted, due to semantics.] First result is new
;; start, if end was not reached. Second result is overall width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type translate translate)
(type index-size size)
(values (or null integer) (or null integer))))
∂25-Jun-87 1255 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: more concrete font proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87 08:12:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Jun 87 11:09-EDT
Date: Thu, 25 Jun 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870625111051.5.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 24 Jun 87 15:34 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
;;; Actually, this type is implementation dependent.
;;; NIL means to use a global default that makes sense for
;;; this implementation.
What is the scope of an "implementation"? Are there assumptions about
character sets and fonts used?
I'm not sure what you're asking. I didn't know implementations had scopes.
Assumptions character sets and fonts used by whom? Where? Huh?
I was really just trying to figure out whether the default global
context had to have knowledge of "non-standard" character features of
the local CL implementation (e.g., si:char-style), and whether it also
had to have knowledge of the font encodings. That is, is it written as
part of CLX, or is it written for each (CL, CLX) pair, or can it
actually be written at all. Anyway, I think I get the picture.
;;; Perhaps, instead, this should get merged in with a
;;; higher-level view of a gcontext?
Actually adding a component to the CLX-level gcontext might be
reasonable.
Well, how does the higher level get its hands on it. If this
CONTEXT is a stream, then both how did this higher level get
its hands on the GCONTEXT, and how did the GCONTEXT get its
hands on the STREAM, which came from yet a higher level?
I'm not sure I understand the modularity of GCONTEXT's.
Mostly I'm trying to figure out how to make your mini-level "go away"
(see below), but provide necessary capability in CLX.
My intent was that the context is used to derive the translation
function.
(defun get-output-translation-function (context)
(declare (type context context)
(values output-translation-function)))
So what I had in mind was, if you think of a context as something like a
stream, then the stream will likely contain a gcontext to get its work
done, and the stream can itself compute the translation function and
either store it in the gcontext whenever it needs to change, or bind it
using with-gcontext. You can then argue about what translation function
to store when a gcontext is initially created, if one isn't specified.
If this is the essential operation on a context for output, then I don't
see why (at the CLX layer) passing in a context is any better than
passing in a translation function.
;;; We forgot about translation on input! This can safely be
;;; a character-at-a-time unbuffered.
I've been intentionally ignoring this for now, both to avoid confusion
and while awaiting beta release so that people could see the KEYSYM
stuff. The input side isn't the inverse of output (it doesn't convert a
font+index into a character), it needs to convert a KEYSYM+bits+???
into a character.
If translate-string is an example of a context,
Close enough to make the rest of your comment relevant...
then I don't see why
text-display-extents and the other functions you listed care what the
type of the string argument is; presumably it is simply up to the caller
(of text-display-extents) to provide an argument that matches the type
expected for the second argument to transform. It doesn't even need to
be vector, much less have a particular element-type.
This is true. It makes it harder to specify in this
specification-language, though. Do you think this is
worth including explicitly as part of the specification
for this layer?
I don't think it is any harder to specify. Let me try by giving a
variation on your proposal that incorporates a number of changes: it
isn't restricted to strings; it does not have contexts, just translation
functions; it eliminates the call-backs within the translator, and
eliminates the buffer limit; it allows delta-x motion by the translator;
it tries to sort out some problems with 8-bit vs. 16-bit indexing; it
allows the translator to convey width information for request chaining;
it raises various questions.
;; I would write a deftype, but it's easier to have argument names:
(defun translate-skeleton (src src-start src-end font dst dst-start)
;; dst is guaranteed to have room for (- src-end src-start) integer elements,
;; starting at dst-start; whether dst holds 8-bit or 16-bit elements depends
;; on context. font is the current font, if known. The function should
;; translate as many elements of src as possible into indexes in the current
;; font, and store them into dst. The first return value should be the src
;; index of the first untranslated element. If no further elements need to
;; be translated, the second return value should be nil. If a horizontal
;; motion is required before further translation, the second return value
;; should be the delta in x coordinate. If a font change is required for
;; further translation, the second return value should be the new font. If
;; known, the pixel width of the translated text can be returned as the third
;; value; this can allow for appending of subsequent output to the same
;; protocol request, if no overall width has been specified at the higher
;; level.
(declare (type sequence src)
(type integer src-start src-end dst-start)
(type (or null font) font)
(type vector dst)
(values integer (or null integer font) (or null integer))))
;; There is a question below of whether translate should always be required, or
;; if not, what the default should be or where it should come from. For
;; example, the default could be something that expected a string as src and
;; translated the CL standard character set to ASCII indexes, and ignored fonts
;; and bits. Or the default could expect a string but otherwise be "system
;; dependent". Or the default could be something that expected a vector of
;; integers and did no translation. Or the default could come from the
;; gcontext (but what about text-extents and text-width?).
(defun text-extents (sequence &key (start 0) end font translate)
;; If multiple fonts are involved, font-ascent and font-descent will be the
;; maximums. If multiple directions are involved, the direction will be nil.
;; Translate will always be called with a 16-bit dst buffer.
(declare (type sequence sequence)
(type (or null font gcontext) font)
(type translate translate)
(values width ascent descent left right font-ascent font-descent direction
(or null integer))))
(defun text-width (sequence &key (start 0) end font translate)
;; Translate will always be called with a 16-bit dst buffer.
(declare (type sequence sequence)
(type (or null font gcontext) font)
(type translate translate)
(values integer (or null integer))))
;; This controls the element size of the dst buffer given to translate. If
;; :default is specified, the size will be based on the current font, if known,
;; and otherwise 16 will be used. [An alternative would be to pass the buffer
;; size to translate, and allow it to return the desired size if it doesn't
;; like the current size. The problem is that the protocol doesn't allow
;; switching within a single request, so to allow switching would require
;; knowing the width of text, which isn't necessarily known. We could call
;; text-width to compute it, but perhaps that is doing too many favors?] [An
;; additional possibility is to allow an index-size of :two-byte, in which case
;; translate would be given a double-length 8-bit array, and translate would be
;; expected to store first-byte/second-byte instead of 16-bit integers.]
(deftype index-size () '(member :default 8 16))
;; In the functions below, if width is specified, it is assumed to be the total
;; pixel width of whatever string of glyphs is actually drawn. Specifying
;; width will allow for appending the output of subsequent calls to the same
;; protocol request, provided gcontext has not been modified in the interim.
;; If width is not specified, appending of subsequent output might not occur
;; (unless translate returns the width). Specifying width is simply a hint,
;; for performance.
(defun draw-glyph (drawable gcontext x y elt
&key translate width (size :default))
;; Returns true if elt is output, nil if translate refuses to output it.
;; Second result is width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type translate translate)
(type (or null integer) width)
(type index-size size)
(values boolean (or null integer))))
(defun draw-glyphs (drawable gcontext x y sequence
&key (start 0) end translate width (size :default))
;; First result is new start, if end was not reached. Second result is
;; overall width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type translate translate)
(type index-size size)
(values (or null integer) (or null integer))))
(defun draw-image-glyph (drawable gcontext x y elt
&key translate width (size :default))
;; Returns true if elt is output, nil if translate refuses to output it.
;; Second result is overall width, if known. An initial font change is
;; allowed from translate.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type translate translate)
(type (or null integer) width)
(type index-size size)
(values boolean (or null integer))))
(defun draw-image-glyphs (drawable gcontext x y sequence
&key (start 0) end width translate (size :default))
;; An initial font change is allowed from translate, but any subsequent font
;; change or horizontal motion will cause termination (because the protocol
;; doesn't support chaining). [Alternatively, font changes could be accepted
;; as long as they are accompanied with a width return value, or always
;; accept font changes and call text-width as required. However, horizontal
;; motion can't really be accepted, due to semantics.] First result is new
;; start, if end was not reached. Second result is overall width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type translate translate)
(type index-size size)
(values (or null integer) (or null integer))))
∂25-Jun-87 1309 CS.WERTH@R20.UTEXAS.EDU Re: more concrete font proposal
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87 13:08:50 PDT
Date: Thu 25 Jun 87 15:06:50-CDT
From: CS.WERTH@R20.UTEXAS.EDU
Subject: Re: more concrete font proposal
To: RWK@SCRC-YUKON.ARPA
cc: sas@BFLY-VAX.BBN.COM, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870619063826.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <12313385522.18.CS.WERTH@R20.UTEXAS.EDU>
I also plan to attend the Evening Grants Meeting.
J Werth
-------
∂25-Jun-87 1357 @RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET Re: CLX beta changes
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87 13:56:39 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa06017; 25 Jun 87 14:25 EDT
Received: from ti-csl by RELAY.CS.NET id aa20741; 25 Jun 87 14:16 EDT
Received: by tilde id AA11291; Thu, 25 Jun 87 12:52:54 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 25 Jun 87 12:54:45 CDT
Message-Id: <2760630731-15842445@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Thu, 25 Jun 87 12:52:11 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX beta changes
In-Reply-To: Msg of Wed, 24 Jun 87 13:44 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
>(defun set-modifier-mapping (display &key shift lock control
> mod1 mod2 mod3 mod4 mod5)
>;; Should this signal device-busy like the pointer-mapping
>;; setf, and return a boolean instead (true for
>;; success)?
Yes, I think this alternative strikes the right balance between
consistency and aptness of interface.
>(defun modifier-mapping (display)
>;; each value is either nil, a single integer, or a list of two integers
> (declare (type display display)
> (values shift lock control mod1 mod2 mod3 mod4 mod5)))
What's the interpretation of assigning a modifier two keycodes?
>;; Either we will want lots of defconstants for well-known values, or perhaps
>;; an integer-to-keyword translation function for well-known values.
>
>(deftype keysym () 'integer)
I'd vote for defconstants and/or a pair of keyword-to-keysym/keysym-to-keyword
translation functions. These would be used for setting/inquiring the keyboard
mapping.
It seems that clients have a vital interest in using and maintaining the current
KEYCODE-to-keysym mapping. To ignore this is not only non-portable (the mapping
is a client's only clue to the significance of the keycodes received from a
remote display), but also may result in a total breakdown of the client's user
interface. Should not CLX therefore provide more support in this area?
Hopefully, this could be a simple "wheel" that no one would then have to
reinvent. Something like:
(defun keycode-symbol (display keycode modifier-state)
;; Return the keycap symbol currently assigned to a display's keycode,
;; for the given modifier state.
;; Creates (if necessary) and uses a local copy of the keyboard mapping
(declare (type display display)
(type integer keycode)
;; Should return keyword if keysym defconstants are not provided
(values keysym-or-keyword)))
(defun handle-mapping-notify (&rest keywords)
;; Default event handler for MappingNotify events. Creates (if necessary)
;; and updates local keyboard/modifier mappings used to implement
;; keycode-symbol
)
[PS: Isn't it correct that the server directly uses the pointer mapping,
returning only "mapped" button codes? Likewise, does the server directly use
the modifier mappings, returning modifier state in events accordingly? If
"yes", then what is a client supposed to do with a MappingNotify event when
(member request (:pointer :modifier))? If "no", then facilities similar to
above would be needed to allow clients to track these mappings.]
[PPS: What about the relationship between keysyms and font indices? That is,
the information needed simply (but portably!) to echo keyboard input. Now that
the keysym registry is available, shouldn't X require fonts to allow clients to
inquire this relationship?]
>(defun change-keyboard-mapping (display keysyms &key (start1 0) end1 (start2 start1))
>;; start1/end1 give subrange of keysyms
>;; start2 is the first-keycode to store at
>;; are there better argument names?
How about start-from, end-from, and start-to? By the way, can't keysyms be a
sequence of n-element sequences. Can't n be > 2?
∂25-Jun-87 1438 CS.WERTH@R20.UTEXAS.EDU Re: more concrete font proposal
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87 13:08:50 PDT
Date: Thu 25 Jun 87 15:06:50-CDT
From: CS.WERTH@R20.UTEXAS.EDU
Subject: Re: more concrete font proposal
To: RWK@SCRC-YUKON.ARPA
cc: sas@BFLY-VAX.BBN.COM, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870619063826.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <12313385522.18.CS.WERTH@R20.UTEXAS.EDU>
I also plan to attend the Evening Grants Meeting.
J Werth
-------
∂25-Jun-87 1505 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: more concrete font proposal
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87 08:12:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Jun 87 11:09-EDT
Date: Thu, 25 Jun 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870625111051.5.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 24 Jun 87 15:34 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
;;; Actually, this type is implementation dependent.
;;; NIL means to use a global default that makes sense for
;;; this implementation.
What is the scope of an "implementation"? Are there assumptions about
character sets and fonts used?
I'm not sure what you're asking. I didn't know implementations had scopes.
Assumptions character sets and fonts used by whom? Where? Huh?
I was really just trying to figure out whether the default global
context had to have knowledge of "non-standard" character features of
the local CL implementation (e.g., si:char-style), and whether it also
had to have knowledge of the font encodings. That is, is it written as
part of CLX, or is it written for each (CL, CLX) pair, or can it
actually be written at all. Anyway, I think I get the picture.
;;; Perhaps, instead, this should get merged in with a
;;; higher-level view of a gcontext?
Actually adding a component to the CLX-level gcontext might be
reasonable.
Well, how does the higher level get its hands on it. If this
CONTEXT is a stream, then both how did this higher level get
its hands on the GCONTEXT, and how did the GCONTEXT get its
hands on the STREAM, which came from yet a higher level?
I'm not sure I understand the modularity of GCONTEXT's.
Mostly I'm trying to figure out how to make your mini-level "go away"
(see below), but provide necessary capability in CLX.
My intent was that the context is used to derive the translation
function.
(defun get-output-translation-function (context)
(declare (type context context)
(values output-translation-function)))
So what I had in mind was, if you think of a context as something like a
stream, then the stream will likely contain a gcontext to get its work
done, and the stream can itself compute the translation function and
either store it in the gcontext whenever it needs to change, or bind it
using with-gcontext. You can then argue about what translation function
to store when a gcontext is initially created, if one isn't specified.
If this is the essential operation on a context for output, then I don't
see why (at the CLX layer) passing in a context is any better than
passing in a translation function.
;;; We forgot about translation on input! This can safely be
;;; a character-at-a-time unbuffered.
I've been intentionally ignoring this for now, both to avoid confusion
and while awaiting beta release so that people could see the KEYSYM
stuff. The input side isn't the inverse of output (it doesn't convert a
font+index into a character), it needs to convert a KEYSYM+bits+???
into a character.
If translate-string is an example of a context,
Close enough to make the rest of your comment relevant...
then I don't see why
text-display-extents and the other functions you listed care what the
type of the string argument is; presumably it is simply up to the caller
(of text-display-extents) to provide an argument that matches the type
expected for the second argument to transform. It doesn't even need to
be vector, much less have a particular element-type.
This is true. It makes it harder to specify in this
specification-language, though. Do you think this is
worth including explicitly as part of the specification
for this layer?
I don't think it is any harder to specify. Let me try by giving a
variation on your proposal that incorporates a number of changes: it
isn't restricted to strings; it does not have contexts, just translation
functions; it eliminates the call-backs within the translator, and
eliminates the buffer limit; it allows delta-x motion by the translator;
it tries to sort out some problems with 8-bit vs. 16-bit indexing; it
allows the translator to convey width information for request chaining;
it raises various questions.
;; I would write a deftype, but it's easier to have argument names:
(defun translate-skeleton (src src-start src-end font dst dst-start)
;; dst is guaranteed to have room for (- src-end src-start) integer elements,
;; starting at dst-start; whether dst holds 8-bit or 16-bit elements depends
;; on context. font is the current font, if known. The function should
;; translate as many elements of src as possible into indexes in the current
;; font, and store them into dst. The first return value should be the src
;; index of the first untranslated element. If no further elements need to
;; be translated, the second return value should be nil. If a horizontal
;; motion is required before further translation, the second return value
;; should be the delta in x coordinate. If a font change is required for
;; further translation, the second return value should be the new font. If
;; known, the pixel width of the translated text can be returned as the third
;; value; this can allow for appending of subsequent output to the same
;; protocol request, if no overall width has been specified at the higher
;; level.
(declare (type sequence src)
(type integer src-start src-end dst-start)
(type (or null font) font)
(type vector dst)
(values integer (or null integer font) (or null integer))))
;; There is a question below of whether translate should always be required, or
;; if not, what the default should be or where it should come from. For
;; example, the default could be something that expected a string as src and
;; translated the CL standard character set to ASCII indexes, and ignored fonts
;; and bits. Or the default could expect a string but otherwise be "system
;; dependent". Or the default could be something that expected a vector of
;; integers and did no translation. Or the default could come from the
;; gcontext (but what about text-extents and text-width?).
(defun text-extents (sequence &key (start 0) end font translate)
;; If multiple fonts are involved, font-ascent and font-descent will be the
;; maximums. If multiple directions are involved, the direction will be nil.
;; Translate will always be called with a 16-bit dst buffer.
(declare (type sequence sequence)
(type (or null font gcontext) font)
(type translate translate)
(values width ascent descent left right font-ascent font-descent direction
(or null integer))))
(defun text-width (sequence &key (start 0) end font translate)
;; Translate will always be called with a 16-bit dst buffer.
(declare (type sequence sequence)
(type (or null font gcontext) font)
(type translate translate)
(values integer (or null integer))))
;; This controls the element size of the dst buffer given to translate. If
;; :default is specified, the size will be based on the current font, if known,
;; and otherwise 16 will be used. [An alternative would be to pass the buffer
;; size to translate, and allow it to return the desired size if it doesn't
;; like the current size. The problem is that the protocol doesn't allow
;; switching within a single request, so to allow switching would require
;; knowing the width of text, which isn't necessarily known. We could call
;; text-width to compute it, but perhaps that is doing too many favors?] [An
;; additional possibility is to allow an index-size of :two-byte, in which case
;; translate would be given a double-length 8-bit array, and translate would be
;; expected to store first-byte/second-byte instead of 16-bit integers.]
(deftype index-size () '(member :default 8 16))
;; In the functions below, if width is specified, it is assumed to be the total
;; pixel width of whatever string of glyphs is actually drawn. Specifying
;; width will allow for appending the output of subsequent calls to the same
;; protocol request, provided gcontext has not been modified in the interim.
;; If width is not specified, appending of subsequent output might not occur
;; (unless translate returns the width). Specifying width is simply a hint,
;; for performance.
(defun draw-glyph (drawable gcontext x y elt
&key translate width (size :default))
;; Returns true if elt is output, nil if translate refuses to output it.
;; Second result is width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type translate translate)
(type (or null integer) width)
(type index-size size)
(values boolean (or null integer))))
(defun draw-glyphs (drawable gcontext x y sequence
&key (start 0) end translate width (size :default))
;; First result is new start, if end was not reached. Second result is
;; overall width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type translate translate)
(type index-size size)
(values (or null integer) (or null integer))))
(defun draw-image-glyph (drawable gcontext x y elt
&key translate width (size :default))
;; Returns true if elt is output, nil if translate refuses to output it.
;; Second result is overall width, if known. An initial font change is
;; allowed from translate.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type translate translate)
(type (or null integer) width)
(type index-size size)
(values boolean (or null integer))))
(defun draw-image-glyphs (drawable gcontext x y sequence
&key (start 0) end width translate (size :default))
;; An initial font change is allowed from translate, but any subsequent font
;; change or horizontal motion will cause termination (because the protocol
;; doesn't support chaining). [Alternatively, font changes could be accepted
;; as long as they are accompanied with a width return value, or always
;; accept font changes and call text-width as required. However, horizontal
;; motion can't really be accepted, due to semantics.] First result is new
;; start, if end was not reached. Second result is overall width, if known.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type sequence sequence)
(type (or null integer) end width)
(type translate translate)
(type index-size size)
(values (or null integer) (or null integer))))
∂25-Jun-87 1438 @RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET Re: CLX beta changes
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87 13:56:39 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa06017; 25 Jun 87 14:25 EDT
Received: from ti-csl by RELAY.CS.NET id aa20741; 25 Jun 87 14:16 EDT
Received: by tilde id AA11291; Thu, 25 Jun 87 12:52:54 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 25 Jun 87 12:54:45 CDT
Message-Id: <2760630731-15842445@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Thu, 25 Jun 87 12:52:11 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX beta changes
In-Reply-To: Msg of Wed, 24 Jun 87 13:44 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
>(defun set-modifier-mapping (display &key shift lock control
> mod1 mod2 mod3 mod4 mod5)
>;; Should this signal device-busy like the pointer-mapping
>;; setf, and return a boolean instead (true for
>;; success)?
Yes, I think this alternative strikes the right balance between
consistency and aptness of interface.
>(defun modifier-mapping (display)
>;; each value is either nil, a single integer, or a list of two integers
> (declare (type display display)
> (values shift lock control mod1 mod2 mod3 mod4 mod5)))
What's the interpretation of assigning a modifier two keycodes?
>;; Either we will want lots of defconstants for well-known values, or perhaps
>;; an integer-to-keyword translation function for well-known values.
>
>(deftype keysym () 'integer)
I'd vote for defconstants and/or a pair of keyword-to-keysym/keysym-to-keyword
translation functions. These would be used for setting/inquiring the keyboard
mapping.
It seems that clients have a vital interest in using and maintaining the current
KEYCODE-to-keysym mapping. To ignore this is not only non-portable (the mapping
is a client's only clue to the significance of the keycodes received from a
remote display), but also may result in a total breakdown of the client's user
interface. Should not CLX therefore provide more support in this area?
Hopefully, this could be a simple "wheel" that no one would then have to
reinvent. Something like:
(defun keycode-symbol (display keycode modifier-state)
;; Return the keycap symbol currently assigned to a display's keycode,
;; for the given modifier state.
;; Creates (if necessary) and uses a local copy of the keyboard mapping
(declare (type display display)
(type integer keycode)
;; Should return keyword if keysym defconstants are not provided
(values keysym-or-keyword)))
(defun handle-mapping-notify (&rest keywords)
;; Default event handler for MappingNotify events. Creates (if necessary)
;; and updates local keyboard/modifier mappings used to implement
;; keycode-symbol
)
[PS: Isn't it correct that the server directly uses the pointer mapping,
returning only "mapped" button codes? Likewise, does the server directly use
the modifier mappings, returning modifier state in events accordingly? If
"yes", then what is a client supposed to do with a MappingNotify event when
(member request (:pointer :modifier))? If "no", then facilities similar to
above would be needed to allow clients to track these mappings.]
[PPS: What about the relationship between keysyms and font indices? That is,
the information needed simply (but portably!) to echo keyboard input. Now that
the keysym registry is available, shouldn't X require fonts to allow clients to
inquire this relationship?]
>(defun change-keyboard-mapping (display keysyms &key (start1 0) end1 (start2 start1))
>;; start1/end1 give subrange of keysyms
>;; start2 is the first-keycode to store at
>;; are there better argument names?
How about start-from, end-from, and start-to? By the way, can't keysyms be a
sequence of n-element sequences. Can't n be > 2?
∂28-Jun-87 1456 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: CLX beta changes
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jun 87 14:56:41 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 28 Jun 87 17:54-EDT
Date: Sun, 28 Jun 87 17:56 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: CLX beta changes
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2760630731-15842445@Sierra>
Message-ID: <870628175604.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 25 Jun 87 12:52:11 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
>(defun modifier-mapping (display)
>;; each value is either nil, a single integer, or a list of two integers
> (declare (type display display)
> (values shift lock control mod1 mod2 mod3 mod4 mod5)))
What's the interpretation of assigning a modifier two keycodes?
The modifier reflects the OR of the two keys (e.g., most keyboards have
both left and right shift keys; if either is down, the Shift bit is
set).
(defun keycode-symbol (display keycode modifier-state)
;; Return the keycap symbol currently assigned to a display's keycode,
;; for the given modifier state.
;; Creates (if necessary) and uses a local copy of the keyboard mapping
(declare (type display display)
(type integer keycode)
;; Should return keyword if keysym defconstants are not provided
(values keysym-or-keyword)))
This can interpret the Shift and Lock modifier bits, since the protocol
suggests the way this should be done. If that is all you intended,
fine. If you also hoped it would interpret Control and the Mod1-5
modifiers, then we have a problem.
[PPS: What about the relationship between keysyms and font indices? That is,
the information needed simply (but portably!) to echo keyboard input. Now that
the keysym registry is available, shouldn't X require fonts to allow clients to
inquire this relationship?]
I suspect what many applications will want is not your keycode-symbol
function, but rather something that translates keycode+modifiers to a
character object, given a current "context" (as RWK called it). The
relationship to font indices is determined by the corresponding output
translation. What kind of default CLX itself provides is probably
closely coupled with your answer for output. For example, if you
believe CLX should provide something for output that translates the CL
standard character set to ASCII indexes, ignoring fonts and bits, then
it should probably also provide something for input that translates
Latin-1 keysyms to the CL standard character set, probably ignoring
Control and Mod1-5.
It probably is desirable to have a set of fonts that index-match the
least significant byte of the standard keysyms. It probably is also
desirable for fonts to have some indication of which character
(sub)set(s) they match. If such things can be agreed upon by the X
community as a whole, then generic translation functions can be defined
that will work most of the time.
[PS: Isn't it correct that the server directly uses the pointer mapping,
returning only "mapped" button codes? Likewise, does the server directly use
the modifier mappings, returning modifier state in events accordingly?
Yes.
If
"yes", then what is a client supposed to do with a MappingNotify event when
(member request (:pointer :modifier))?
Most likely you ignore :pointer change. Whether or not to ignore
:modifier depends on how you interpret Lock and the Mod1-5 bits. Most
likely you want to know whether Lock has changed from Capslock to
Shiftlock. For the Mod1-5 bits, there are two philosophies. One is
that you read their actual keysyms and interpret on that basis (viz.,
what you really care about is whether Meta and Hyper are down, not what
modifier bit they happen to be mapped to). The other is that you assign
semantic interpretation to "Mod1" independent of what keysym happens to
be engraved on it. There are arguments on both sides about which
philosophy leads to the more portable and/or easier to document user
interface.
By the way, can't keysyms be a
sequence of n-element sequences. Can't n be > 2?
Silly me, (array keysym 2) should be (array keysym (* *)) in both
change-keyboard-mapping and keyboard-mapping. As in the protocol,
"unused" entries are zeroed. This seemed to me a bit easier to deal
with both in CLX and the application than (vector (vector keysym)), but
I'm willing to be convinced otherwise.
∂29-Jun-87 0702 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: type confusion
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jun 87 07:02:45 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jun 87 10:01-EDT
Date: Mon, 29 Jun 87 10:02 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: type confusion
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870628175604.2.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870629100249.4.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Sun, 28 Jun 87 17:56 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Silly me, (array keysym 2) should be (array keysym (* *)) in both
change-keyboard-mapping and keyboard-mapping. As in the protocol,
"unused" entries are zeroed. This seemed to me a bit easier to deal
with both in CLX and the application than (vector (vector keysym)), but
I'm willing to be convinced otherwise.
RWK has correctly pointed out to me that, due to the interesting
"features" of the CL type system, (array keysym (* *)) probably doesn't
convey what is desired, namely "a two-dimensional array that *currently*
contains keysyms", rather than "a two-dimensional array that can *only*
contain keysyms". So, although (array keysym (* *)) might be reasonable
as the return type for keyboard-mapping, (array * (* *)) is probably the
correct argument type for change-keyboard-mapping.
∂29-Jun-87 1040 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU with-gcontext question
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jun 87 10:38:30 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jun 87 13:36-EDT
Date: Mon, 29 Jun 87 13:38 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: with-gcontext question
To: Oren%Home%ti-csl.csnet@RELAY.CS.NET
cc: clx@ZERMATT.LCS.MIT.EDU, cl-windows@sail.stanford.edu
In-Reply-To: <2760964923-3321382@SI>
Message-ID: <870629133814.7.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Mon, 29 Jun 87 09:42:03 CDT
From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>
Do you view WITH-GCONTEXT as binding fields within a GC,
or as binding the whole GC?
Very definitely as binding individual components. I had thought this
was clear, but apparently not. I suppose we could rename it to
with-gcontext-components, to mirror copy-gcontext-components (as
distinct from copy-gcontext), if people think that would help, although
it's a pretty long name.
For example, is
(with-gcontext (gc :font foo)
(setf (gcontext-tile gc) pixmap)
...)
The same as:
(with-gcontext (gc)
(setf (gcontext-font gc) foo)
(setf (gcontext-tile gc) pixmap)
...)
No. In fact, the with-gcontext in the second example is a no-op. It
isn't clear to me that a form to bind all components (to their existing
values) is all that useful; that would be sort of like a LET that bound
all extant variables, wouldn't it?
Its my understanding that if the font in GC is unknown (the default)
then with-gcontext creates a temporary copy of GC, then sets the new
font in the copy. When exiting the with-gcontext, the temporary GC is
deleted. How would this be handled for the second case? Can any
gcontext setf cause a transition from modified to copied gcontext?
At the beginning of the with-gcontext you need to snapshot a copy of all
components listed as arguments to the form. If you don't know the
current value of some components, you create (or reuse) a temporary GC
and copy over all listed components for which you don't know the value.
You then do setfs to the new values listed as arguments. These setfs,
like setfs within the body, modify the original GC, not the partial
copy. On exit, you copy back (only) those components you saved.
If these two examples are not equivalent, then does setting the tile in
the example effectively change the tile in two GC's (the original
and the temporary copy)?
No. A gcontext setf never affects the (invisible) copy.
∂29-Jun-87 1122 @RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET Re: CLX beta changes
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Jun 87 11:22:33 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac26006; 29 Jun 87 13:06 EDT
Received: from ti-csl by RELAY.CS.NET id ae13910; 29 Jun 87 13:02 EDT
Received: by tilde id AA07357; Mon, 29 Jun 87 11:12:14 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 29 Jun 87 11:14:37 CDT
Message-Id: <2760970211-3208787@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 29 Jun 87 11:10:11 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX beta changes
In-Reply-To: Msg of Sun, 28 Jun 87 17:56 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
>I suspect what many applications will want is not your
>keycode-symbol function, but rather something that translates
>keycode+modifiers to a character object, given a current
>"context" (as RWK called it). The relationship to font indices
>is determined by the corresponding output translation. What
>kind of default CLX itself provides is probably closely coupled
>with your answer for output. For example, if you believe CLX
>should provide something for output that translates the CL
>standard character set to ASCII indexes, ignoring fonts and
>bits, then it should probably also provide something for input
>that translates Latin-1 keysyms to the CL standard character
>set, probably ignoring Control and Mod1-5.
Agreed. Here's my vote for including these CLX defaults for text
output/input translation. What do you think of also including in CLX a
mechanism for "automatically" tracking the display's current keyboard
mapping in order to maintain the input translation?
>It probably is desirable to have a set of fonts that
>index-match the least significant byte of the standard keysyms.
>It probably is also desirable for fonts to have some indication
>of which character (sub)set(s) they match. If such things can
>be agreed upon by the X community as a whole, then generic
>translation functions can be defined that will work most of the
>time.
Are such proposals already in the works? What do you think is the best
way to integrate this capability into the X protocol? Standard
extension request? New required fontprops (e.g. Latin1StartIndex)?
∂29-Jun-87 1149 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: CLX beta changes
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jun 87 11:49:33 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jun 87 14:47-EDT
Date: Mon, 29 Jun 87 14:49 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: CLX beta changes
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2760970211-3208787@Sierra>
Message-ID: <870629144912.1.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Mon, 29 Jun 87 11:10:11 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
Agreed. Here's my vote for including these CLX defaults for text
output/input translation. What do you think of also including in CLX a
mechanism for "automatically" tracking the display's current keyboard
mapping in order to maintain the input translation?
My feeling is that we need to stop designing soon and start
experimenting. Hopefully an initial implementation of most of CLX will
be available within a very few weeks, and people can really start
playing and building some things. I would like see an "essential"
interface put in place, such that people can start building on it.
Whether some of the things that get built eventually get viewed as part
of CLX or part of a higher-level layer doesn't seem important to me
right now. To me, the existence and exact functionality of "default"
character i/o translators is something that needs to be worked on, but
shouldn't hold up the show, which is one reason I want text output done
in terms of functional arguments. The basic stuff needed for input is
even easier; the existence of input translators is necessary, but are
essentially "convenience" routines that can be provided "on top" without
any basic change to the underlying interface (or at least that seems
plausible).
>It probably is desirable to have a set of fonts that
>index-match the least significant byte of the standard keysyms.
>It probably is also desirable for fonts to have some indication
>of which character (sub)set(s) they match. If such things can
>be agreed upon by the X community as a whole, then generic
>translation functions can be defined that will work most of the
>time.
Are such proposals already in the works? What do you think is the best
way to integrate this capability into the X protocol? Standard
extension request? New required fontprops (e.g. Latin1StartIndex)?
As I think I said in an earlier message, a number of people are very
concerned about this issue, and will be attempting to do something about
it. There are tentative ideas floating around, but no firm proposals
yet. Anyone interested in (seriously) contributing to the effort is
welcome. I don't believe at this point that any changes to the protocol
are required. I think some "layered" standards in terms of font naming
and font properties can go a long way.
∂29-Jun-87 1201 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: draw-image-glyph(s)
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jun 87 12:00:35 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jun 87 14:58-EDT
Date: Mon, 29 Jun 87 15:00 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: draw-image-glyph(s)
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@sail.stanford.edu
In-Reply-To: <2760972786-3363493@Sierra>
Message-ID: <870629150002.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Mon, 29 Jun 87 11:53:06 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
(defun draw-image-glyph (drawable gcontext x y elt
&key translate width (size :default)))
(defun draw-image-glyphs (drawable gcontext x y sequence
&key (start 0) end width translate (size :default)))
Do these functions modify the given gcontext (i.e. change its font) or
do they make gcontext copies?
Is it your intention that the implementation of these functions is free
to choose how far it wants to go in handling font changes?
I want there to be a precise semantics, but I'm not sure exactly what
the best semantics is, given that the underlying protocol requests don't
allow font changes. I would expect that at least an initial font change
would be allowed, and that it would indeed side-effect the gcontext, not
create a copy. Whether further font changes are allowed depends on
whether you allow this routine to make text-width calls internally in
order to generate the successive protocol requests. The question of
horizontal motion is even stickier, since it isn't clear whether the
"white space" should be left unchanged or should be filled with the
background like the rest of the extent. The combination of these would
lead me to say that only an initial font change should be allowed, but I
welcome suggestions.
∂29-Jun-87 2112 @RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET Re: draw-image-glyph(s)
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Jun 87 21:12:03 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa00999; 29 Jun 87 21:01 EDT
Received: from ti-csl by RELAY.CS.NET id as16127; 29 Jun 87 20:50 EDT
Received: by tilde id AA13846; Mon, 29 Jun 87 16:37:49 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 29 Jun 87 16:40:17 CDT
Message-Id: <2760989852-4388876@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 29 Jun 87 16:37:32 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: draw-image-glyph(s)
In-Reply-To: Msg of Mon, 29 Jun 87 15:00 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
(defun draw-image-glyph (drawable gcontext x y elt
&key translate width (size :default)))
(defun draw-image-glyphs (drawable gcontext x y sequence
&key (start 0) end width translate (size :default)))
>I want there to be a precise semantics, but I'm not sure exactly what
>the best semantics is, given that the underlying protocol requests
>don't allow font changes. I would expect that at least an initial font
>change would be allowed, and that it would indeed side-effect the
>gcontext, not create a copy. Whether further font changes are allowed
>depends on whether you allow this routine to make text-width calls
>internally in order to generate the successive protocol requests. The
>question of horizontal motion is even stickier, since it isn't clear
>whether the "white space" should be left unchanged or should be filled
>with the background like the rest of the extent. The combination of
>these would lead me to say that only an initial font change should be
>allowed.
I'm inclined to agree, since it occurs to me that, in order to achieve the
intended effect of draw-image-glyph(s) in a polyfont context, the wise client
will not actually use draw-image-glyph(s) at all! The reason: in order to be
sure the previous background is really "erased", he's going to have to blot out
a rectangle using the "current line height" (i.e. max height over all fonts
used), in which case it will be more efficient to go ahead and use draw-glyphs.
∂30-Jun-87 1023 @RELAY.CS.NET:Oren%Home@TI-CSL.CSNET Re: more concrete font proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 30 Jun 87 10:23:46 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07377; 30 Jun 87 13:06 EDT
Received: from ti-csl by RELAY.CS.NET id ab20827; 30 Jun 87 13:01 EDT
Received: by tilde id AA17405; Tue, 30 Jun 87 11:36:21 CDT
Message-Id: <2761058205-4024875@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 30 Jun 87 11:36:45 CDT
From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: more concrete font proposal
In-Reply-To: Msg of Thu, 25 Jun 87 11:10 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
I gathered that the intent of your latest proposal is to have translate
function do the copy from a text sequence directly into the X server
request buffer. I just noticed that you have the font parameter to
text-extents and text-width typed (or null font gcontext). If the font
is NIL there's no pointer to the display object that contains the
buffer(s). This will require an extra copy, and a resource of
sequences. How about making font a required parameter:
(defun text-extents (font sequence &key (start 0) end translate)
(declare (type (or font gcontext) font)
(type sequence sequence)
(type translate translate)
(values width ascent descent left right font-ascent font-descent direction
(or null integer))))
∂30-Jun-87 1117 @RELAY.CS.NET:Oren%Home@TI-CSL.CSNET Re: more concrete font proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 30 Jun 87 11:16:59 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab07473; 30 Jun 87 13:17 EDT
Received: from ti-csl by RELAY.CS.NET id ai20827; 30 Jun 87 13:12 EDT
Received: by tilde id AA15742; Tue, 30 Jun 87 10:53:59 CDT
Message-Id: <2761055643-3870990@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 30 Jun 87 10:54:03 CDT
From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: more concrete font proposal
In-Reply-To: Msg of Thu, 25 Jun 87 11:10 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
In general, I like your proposal. However, I don't understand why the
text functions need to accept SEQUENCEs. Why aren't vectors sufficient?
I don't understand why anyone would cons up a list of characters when
its just as easy and more efficient to make a vector.
∂30-Jun-87 1431 RWS@ZERMATT.LCS.MIT.EDU Re: why sequences?
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Jun 87 14:30:53 PDT
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 60885; Tue 30-Jun-87 17:29:17 EDT
Date: Tue, 30 Jun 87 17:29 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: why sequences?
To: Oren%Home%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2761055643-3870990@SI>
Message-ID: <870630172953.7.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 30 Jun 87 10:54:03 CDT
From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>
In general, I like your proposal. However, I don't understand why the
text functions need to accept SEQUENCEs. Why aren't vectors sufficient?
I don't understand why anyone would cons up a list of characters when
its just as easy and more efficient to make a vector.
If you think about it, the only way in which CLX itself (as opposed to
the translator passed in) needs to manipulate the sequence object is to
compute the END argument when it isn't explicitly given, i.e., it needs
to do (LENGTH sequence). This doesn't seem an undue burden, and to me
is a desirable flexibility. (In fact, one might be tempted to document
that if both start and end are given, then the "sequence" argument need
not even be a sequence, and if LENGTH ever becomes a generic function,
you are home free.) The other question you can ask, "must the
'standard' translators accept sequences, or are vectors sufficient" is a
perfectly valid question, and it certainly wouldn't bother me if they
only accepted vectors.
∂30-Jun-87 1450 RWS@ZERMATT.LCS.MIT.EDU Re: more concrete font proposal
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Jun 87 14:50:46 PDT
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 60888; Tue 30-Jun-87 17:39:26 EDT
Date: Tue, 30 Jun 87 17:40 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: Oren%Home%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2761058205-4024875@SI>
Message-ID: <870630174001.9.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 30 Jun 87 11:36:45 CDT
From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>
I gathered that the intent of your latest proposal is to have translate
function do the copy from a text sequence directly into the X server
request buffer.
Or at least to allow that to happen.
I just noticed that you have the font parameter to
text-extents and text-width typed (or null font gcontext). If the font
is NIL there's no pointer to the display object that contains the
buffer(s). This will require an extra copy, and a resource of
sequences. How about making font a required parameter:
(defun text-extents (font sequence &key (start 0) end translate)
(declare (type (or font gcontext) font)
(type sequence sequence)
(type translate translate)
(values width ascent descent left right font-ascent font-descent direction
(or null integer))))
That seems acceptable to me. An addition might be to make it
(or display font gcontext).
∂16-Jul-87 0708 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU CLX
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jul 87 07:08:12 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 16 Jul 87 10:05-EDT
Date: Thu, 16 Jul 87 10:06 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX
To: edsel!vesuvius!liz@navajo.stanford.edu
cc: xbeta-sites@ATHENA.MIT.EDU, cl-windows@sail.stanford.edu
In-Reply-To: <8707141656.AA09865@vesuvius.edsel.uucp>
Message-ID: <870716100615.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 14 Jul 87 09:56:12 PDT
From: edsel!vesuvius!liz@navajo.stanford.edu (Liz Heller)
Do you know when a public domain CLX implementation will be
available?
An implementation will be available very soon now for limited alpha
testing. There was a delay while waiting for the Sun server port to get
fixed, so that some basic testing could get done. Anyone interested in
alpha testing the code should send me mail ASAP. I would like to know
what Common Lisp you are going to use, and anything else you think would
help argue your case. If you aren't an X11 beta site, then I definitely
need to know what you think you're going to do.
Could you hazard a guess as to how much effort it
is to implement CLX?
The current sources are about 10K lines of code. LaMott Oren of Texas
Instruments has been working on the code perhaps half time, I think
since about the beginning of May.